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ABSTRACT 


This  thesis  will  focus  on  field  testing  and  evaluating 
the  capabilities  of  a  smartphone-based  system  and  associated 
equipment  for  "First  Responder  Networking."  Further,  we 
will  identify  information  sharing  requirements  for 
supporting  a  medical  triage  tasking  during  mass  casualty  and 
humanitarian  operations.  These  requirements  will  be 
implemented,  tested  and  evaluated  against  the  capabilities 
of  the  TwiddleNet  system  for  passing/sharing  of  patient 
information  and  records,  in  the  form  of  text,  photos  and 
voice,  rapidly  disseminated  to  those  involved  with  the 
Mobile  Emergency  Command  Post  unit  and  the  Joint  Operations 
Command  Center.  This  will  facilitate  communication  via 
synchronized  backhaul  or  satellite  communique  from  the 
disaster  site  to  other  medical  facilities  across  a  globally 
distributed  network.  For  example,  land  based  military 
medical  units,  naval  hospital  ships,  stateside  medical 
centers  via  tele-medicine,  etc.  The  applicability  of  these 
efforts  to  the  DoD  will  be  specifically  tested  via 
integrated  mass  casualty/ triage  scenarios  and  simulated 
humanitarian  operations. 
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I. 


INTRODUCTION 


Today's  smartphones  are  just  as  powerful  as  regular 
personal  computers  (PCs)  were  a  few  years  ago.  Their 
advanced  capabilities  can  support  a  number  of  smartphone- 
based  systems.  These  powerful  devices  can  be  converted  to 
personal  servers  to  be  used  for  instantaneous  data  capture 
and  dissemination  in  support  of  "First  Responder  Information 
Sharing."  This  thesis  tests  and  evaluates  the  capabilities 
of  a  smartphone-based  system  and  associated  equipment  for 
"First  Responder  Networking."  TwiddleNet,  a  wireless  system 
implemented  using  handheld-based  infrastructure,  is  the 
First  Responder  application  used  as  the  platform  for 
instantaneous  data  capture  and  dissemination. 

A.  DEFINITION  OF  TWIDDLE 

Definition:  (Verb)  -  To  twist,  move,  or  fiddle  with 

something,  typically  in  a  purposeful  or  nervous  way. 

1.  Twiddle  one's  thumbs  -  rotate  one's  thumbs  around 
each  other  with  the  fingers  linked  together. 

2 .  Be  bored  or  idle  because  one  has  nothing  to  do 

Today' s  cell  phones  are  constantly  twiddling...  awaiting 
calls  or  data  to  be  passed! 

B.  TWIDDLENET  APPLICATIONS 

1 .  Advanced  Handheld  Communications  Hardware 

Use  of  advanced  handheld  communications  hardware  via 
smartphones  to  facilitate: 
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a.  Instantaneous  capture  of  data  in  support  of 
medical  triage  that  can  be  tagged  and  disseminated  using  any 
accessible  mobile  WiFi  network. 

b.  Mobile  Emergency  Command  Post  team  members  and 
First  Responder  groups  maintain  complete  autonomy  of  all 
captured  data,  which  is  shared  among  specified  team  members, 
stored  for  redundancy  by  the  Mobile  Emergency  Command  Post 
server  and  later  discriminately  disseminated  or  shared. 

c.  System  parameters  that  allow  exploitation  of 
multiple  communications  that  are  limited  only  by  the 
physical  limits  of  the  communications,  which  in  turn  are 
limited  only  by  the  physical  limits  of  the  hardware 

2 .  Gateway 

A  gateway  is  established  involving  mobile  personal 
servers  that  run  on  networked  handheld  devices  or 
smartphones  where  the  server  content  is  completely 
autonomous.  The  privacy  of  personal  information  remains 
intact  due  to  the  contained  WiFi  network  cloud  that  is 
created  by  the  TwiddleNet  access  point,  or  the  private  local 
WiFi  cloud  maintained  by  the  Network  Operations  Center  (NOC) 
of  the  onsite  Command  and  Control  Center. 

C .  PRIMARY  OBJECTIVES 

Our  primary  objectives  will  be  to  determine  the 
functional  performance  of  the  TwiddleNet  system  and  document 
software  developments  as  it  relates  to  First  Responder 
capabilities  and  medical  triage.  This  work  will  identify 
on  identifying  sharing  requirements  for  supporting  scalable 
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medical  triage  tasking  teams  during  mass  casualty  and 
humanitarian  operations  and  perform  a  system-level  test  and 
evaluation  of  the  TwiddleNet  system. 

D.  SMARTPHONE  CAPABILITIES  OF  CONTENT  CAPTURE 

The  smartphone  capabilities  for  data  content  capture 
include : 

•  Immediate  content  capture  and  dissemination. 

•  Full  autonomy  of  content  and  data. 

•  Instantaneous  data  tagging. 

•  Selected  group  sharing. 

E.  PRIVACY  REQUIREMENTS  FOR  FIRST  RESPONDERS 

1 .  General  Specifications 

There  must  be  a  separation  of  information  from 
different  domains  and  groups  using  the  same  system  in  the 
local  TwiddleNet  network  or  local  adhoc  network.  This  will 
allow  access  to  content  and  data  by  First  Responder  team 
members,  which  is  otherwise  inaccessible  to  individuals 
outside  of  the  First  Responder  teams;  and  a  Push/Pull 
coordination  for  all  data,  to  facilitate  data  being  "Pushed" 
to  specified  recipients  and  data  that  can  be  accessed  and 
downloaded  by  any  recipient  or  team  member. 

2 .  Specific  Requirements 

a.  Local  adhoc  networks  or  access  to  the  TwiddleNet 

Mobile  network,  with  a  dedicated  block  of  IP  addresses  to 
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accommodate  all  TwiddleNet  components.  This  will  provide 
closed  communication  with  the  local  network  administrator 
and  provide  a  standard  of  understanding  by  all  users  within 
the  local  network,  not  to  interfere  with  dedicated  IP 
addresses  for  the  TwiddleNet  system. 

b.  Many  privacy  threats  related  to  mobile  networks 
are  a  constant  issue  within  the  Information  Operations 
Domain.  The  Military  must  protect  communications  related  to 
force  protection  to  mitigate  threats  to  content  privacy. 
Safeguarding  all  personal  information,  with  respect  to 
medical  triage  operations,  is  a  criticality. 

c.  Our  testing  will  assume  that  eavesdropping  and 
surveillance  are  not  being  conducted.  Our  testing  is 
focused  on  the  functional  requirements  rather  than  the 
security  of  the  network. 

F.  OBJECTIVES 

1.  Test  and  Evaluate  Deployment 

Our  objective  is  to  test  and  evaluate  the  TwiddleNet 
System  and  the  setup  of  the  TwiddleNet  Mobile  Emergency 
Command  Post  for  First  Responder  teams  in  support  of 
Humanitarian  Assistance  missions  and  Medical  Triage 
operations . 

2.  Research  Question 

a.  "How  can  the  DoD  deploy  a  Mobile  Emergency  Command 
Post  for  'First  Responder  Capability'  when  there  is  no 
available  network  infrastructure?" 
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3.  Secondary  Research  Questions 


a.  "How  can  victims  be  medically  triaged  and 
information  stored  and  disseminated  across  a  globally  shared 
network?" 

b.  "What  is  the  current  and  future  state  of  the  DoD' s 
on-site  disaster  'First  Responder  Capabilities'  and  Mobile 
Emergency  Command  Posts?" 

G.  SCOPE 

Interest  is  focused  on  test  and  evaluation  of  the 
following : 

1.  Information  capture  and  sharing  within  groups  of 
authorized  users. 

2.  TwiddleNet  group  streaming  capabilities. 

3.  Group  sharing  options  within  the  local  adhoc 
network  or  the  TwiddleNet  Mobile  Network. 

4.  Utilization  of  TwiddleNet  Fly  Away  Kit  (FLAK)  for 
deployment  of  rapid  response  teams. 

5.  Utilization  of  the  "TwiddleNet  Gateway"  abilities 
to  communicate  with  specified  receivers  (e.g.,  NFS 
TwiddleNet  Network  Lab)  . 

6.  Incorporation  of  satellite  communications  via  a 
Broadband  Global  Area  Network  (B-GAN)  to  create  a  stable 
backbone  for  reach-back  options  to  other  distant  or  global 
medical  facilities. 

HP  iPAQ  smartphones  with  mobile  network  system 
capabilities  will  be  used  as  a  platform  for  the  TwiddleNet 
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system  implementation.  The  scope  is  limited  to  changes  to 
the  TwiddleNet  software  and  architecture  and  the  equipment 
capabilities . 

The  research  is  limited  to  the  application  layer  of  the 
OSI  Reference  Model  as  changes  to  the  operating  system  and 
network  stack  are  beyond  the  availability  and  visibility  of 
the  researcher. 

Testing  will  be  conducted  during  specified  field 
scenarios  equivalent  to  natural  disasters  such  as  Hurricane 
Katrina,  the  Boxing  Day  Tsunami  of  2004,  and  other  types  of 
mass  casualty  circumstances. 

H .  ORGANI ZATION/METHODOLOGY 

Research  will  be  conducted  in  the  following  phases: 

1.  Phase  1:  Development  of  Metrics  and  Test  Plan 

This  phase  will  include  the  necessary  academic  review 
of  existing  technical  material  and  hardware  for  the 
TwiddleNet  network.  Measure  of  Performance  and  Measure  of 
Effectiveness  (MOP/MOE)  will  be  created.  These  MOPs/MOEs 
will  be  used  to  develop  an  effective  test  and  evaluation 
plan . 


2 .  Phase  2 :  Base-Lining  and  Experimentation 

This  will  be  an  overview  of  the  utilization  of  testing 
and  evaluation  plan  used  with  the  TwiddleNet  system  when 
integrated  with  various  streams  of  the  network  data.  The 
TwiddleNet  System  will  be  connected  to  the  Naval 
Postgraduate  School  (NPS)  Cooperative  Operations  and  Applied 
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Science  and  Technology  Studies  (COASTS)  adhoc  network  during 
the  following  Field  Experiments  (FEX) : 

a.  2008  COASTS  Camp  Roberts  EEX  III. 

b.  2008  COASTS  Thailand  EEX  IV/V. 

c.  2009  COASTS  Camp  Roberts  EEX  II/III. 

During  these  exercises,  determination  of  usefulness  and 
operating  procedures  for  future  use  within  a  DoD  supported 
network  will  be  explored.  The  TwiddleNet  system  will  be 
connected  to  multiple  networks  in  other  operating 
environments  through  satellite  communication  utilizing  a  B- 
GAN  while  the  TwiddleNet  team  is  deployed  to  remote  areas, 
such  as  Thailand,  to  further  the  perspectives  of  system 
effectiveness.  The  TwiddleNet  team  will  utilize  the  Gateway 
Application  (introduced  in  the  4^*^  Iteration)  for  reach-back 
to  global  or  remote  C2  sites  (e.g.,  NFS  TwiddleNet  Lab, 
Joint  Operations  Command  and  Control  ( JOCC) /Tactical 
Operations  Center  (TOC) ) 

3.  Phase  3:  Analysis  of  Results  and  Conclusions 

The  final  phase  will  consist  of  analyzing  the  results 
of  each  case  study  and  each  simulated  natural  disaster 
scenario.  The  results  will  be  compared  to  the  baselined 
system  and  compared  to  the  MOP/MOEs  determined  in  Phase  1 . 

By  comparing  the  results  from  the  case  studies  to  the 
baseline  and  MOP/MOE's,  it  will  be  possible  to  determine  the 
effectiveness  and  feasibility  of  deploying  the  system  in 
real-world  DoD  environments. 
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I.  CHAPTER  OUTLINE  DESCRIPTION 

Chapter  I  gave  a  brief  introduction  to  the  TwiddleNet 
System.  This  encompassed  the  primary  objectives  of  this 
work,  the  proposed  applications,  general  and  specific  system 
requirements,  and  the  scope  and  methodology  utilized  for  the 
evaluation  of  the  TwiddleNet  System. 

Chapter  II  will  provide  an  extensive  background  narration 
of  the  first  three  TwiddleNet  iterations.  This  chapter  will 
also  include  a  breakdown  of  the  TwiddleNet  Architecture  and 
the  pros,  cons,  design  and  operational  issues  for  the  first 
three  TwiddleNet  iterations. 

Chapter  III  will  provide  the  specific  metrics  used  for 
determination  of  feasibility  of  TwiddleNet  iterations  1-3. 
An  overview  of  applicable  areas  of  use  will  be  provided, 
along  with  a  thorough  description  of  each  TwiddleNet 
Hardware  Component . 

Chapter  IV  will  provide  an  extensive  description  of 
Fourth  Generation  TwiddleNet,  to  include  pros,  cons  and 
design  flaws. 

Chapter  V  will  describe  the  testing  methods  used.  This 
will  include  a  breakdown  of  the  Measures  of  Performance 
(MOPs)  and  Measures  of  Effectiveness  (MOEs) . 

Chapter  VI  will  explain  the  different  scenarios  and 
testing  venues  that  incorporated  all  four  iterations  of 
TwiddleNet,  to  include  test  data  and  results  of  the  first 
three  iterations. 
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Chapter  VII 
discussing  how 
applications  and 


will  provide  summary  and  conclusions; 
TwiddleNet  can  be  incorporated  into  DoD 
future  work  for  the  TwiddleNet  System. 
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II .  BACKGROUND 


This  section  provides  a  general  overview  of  the 
TwiddleNet  system  as  applicable  to  a  medical  triage 
application.  Additional  preamble  will  include  specifics  of 
the  TwiddleNet  architecture  and  historical  details  of  the 
TwiddleNet  iterations  throughout  its  2.5-year  evolution. 

A.  TWIDDLENET  OVERVIEW 

Today's  smartphones  are  no  longer  just  phones;  they  are 
no  longer  used  for  just  vocal  communications.  They  are  just 
as  powerful  as  regular  personal  computers  (PCs)  were  a  few 
years  ago.  They  contain  at  least  600  MHz  processors,  going 
as  high  as  1  GHz  (in  the  very  near  future)  .  For  the  new 
models  of  smartphones,  their  memory  is  often  256  Mbytes  with 
an  unlimited  amount  of  storage  capacity. 

But  there  are  at  least  two  important  reasons  that 
illustrate  why  these  little  handheld  devices  are  profoundly 
better  than  a  PC  for  certain  applications: 

1.  Content  Capture  Capability  -  These  handheld 
devices  come  pre-equipped  with  the  capability  to  capture 
images,  video,  sound,  and  text. 

2.  Networking  Capability  -  There  are  at  least  four 
types  of  networking  capability  built  into  today' s 
smartphones:  Global  System  for  Mobile  communication  (GSM), 
2.5  or  3.0  Gig  high-speed  networking.  Wireless  Fidelity 
(WiFi)  and  Bluetooth.  All  of  these  networking  modalities 
are  readily  available  on  this  little  handheld  device. 


11 


This  power  can  basically  enable  instantaneous  and  real¬ 
time  content  capture  and  dissemination  among  first 
responders  or  military  units  through  the  powerful  means  of 
TwiddleNet . 

TwiddleNet  exploits  a  smartphone-based  networking 
system  to  harness  the  untapped  resources  to  create  an 
autonomous  network  of  personal  mobile  servers.  Its 

usefulness  in  scalability  allows  for  adjustment  to  any 
operational  size,  either  planned  or  "on  the  fly"  emphasizing 
the  high  level  of  success  for  any  mission. 

1 .  Medical  Triage  and  Information  Sharing 

Throughout  history,  natural,  accidental  and  willful 
disasters  have  had  profound  effects  on  a  global  scale.  On  a 
macro  level,  the  persistent  challenges  met  by  first 
responders  at  each  major  disaster  site  are  a  lack  of  a 
communications  system,  a  preponderance  of  fractured 
structures,  a  lack  of  situational  awareness,  fractured 
command  and  control  organization  and  retarded  deployment  of 
resources.  Tragedies  such  as  Hurricane  Katrina  in  2005,  the 
September  11  attacks  of  2001,  the  Oklahoma  City  bombing  in 
1995  and  Hurricane  Andrew  in  1992,  medical  triaging 
involving  first  responders,  firefighters,  police  and 
military  elements,  have  gleaned  from  lessons  learned  due  to 
communication  failures.  A  reliable  communication  and 

networking  system  is  critical  within  the  first  24-48  hours 
of  responding  to  a  disaster. 

In  the  realm  of  crisis  and  disaster  response,  the 

advent  of  "Hastily  Formed  Networks,"  (Denning,  2006)  has 

emerged  as  a  strong  solution  to  support  the  communication 
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challenge  of  any  major  disaster.  And  within  this  realm, 
TwiddleNet  has  secured  a  position  as  a  viable  and  worthwhile 
initiative.  The  TwiddleNet  system  was  created  and 
inaugurated  in  2005  by  two  Naval  Postgraduate  Students  (NFS) 
enrolled  in  the  Computer  Science  department,  Capt .  Jonathan 
Towle,  USMC,  and  LT  Christopher  Clotfelter,  USN  [1]  .  The 
students  recognized  the  immense  communication  power  within 
today's  mobile  devices,  offering  a  variable  range  of  content 
capturing  capabilities,  to  include  acceptably  high 
resolution  pictures,  videos  and  sound/voice  recordings. 
They  also  recognized  the  significant  evolutionary  processing 
power  of  current  mobile  devices,  surpassing  that  of  legacy 
PCs  of  less  than  four  years  ago.  And  finally,  they 
recognized  that  a  strong  need  existed  to  streamline  the 
communication  process  for  deployed  first  responder  units;  to 
eliminate  the  requirements  to  bring  large,  bulky  components 
on  site  or  into  the  field  to  capture,  upload  and  disseminate 
important  data  among  the  field  team  members  and  to  the 
Command  and  Control  center. 

B.  TWIDDLENET  ARCHITECTURE 

1.  TwiddleNet  System 

The  TwiddleNet  system  was  designed  to  allow  users  to 
utilize  smartphones  as  personal  servers;  to  capture  or 
gather  information  and  data  and  share  instantaneously  within 
a  protected  WiFi  cloud.  The  premise  is  based  on  a 
"Push/Pull"  technology,  designed  to  allow  users  to  "push" 
information  to  active  recipients  and  team  members  or  for 
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these  same  team  members  to  "pull"  information  from  the 
system  database  for  instantaneous  download  onto  their 
personal  handheld  device. 

This  model  of  content  sharing  is  fundamentally 
different  from  content  sharing  in  other  portals  such  as 
Flickr  1  and  You  Tube  ^  because  after  the  data  is  captured, 
it  must  then  be  uploaded  onto  the  portal  using  a  PC  to  allow 
others  to  see  it.  The  consequences  that  accompany  this  mode 
are : 


a . 

This 

takes  time 

b . 

This 

is  harder  to  use 

c . 

The 

content  is  under  someone  else' 

s  control 

d . 

Data 

is  exposed  to  the 

public  Internet 

But 

with 

the  TwiddleNet 

approach. 

the 

content  is 

captured. 

automatically  tagged. 

alerts  are 

sent 

out  to  all 

team  members,  and  whoever  receives  an  alert  can  retrieve  the 
data  with  their  own  handheld  devices.  And  this,  "Smart 
Push/Pull"  data  processing  is  a  catalyst  in  the  quest  for 
information  superiority  and  Network-Centric  Warfare  [16]. 

2 .  TwiddleNet  Programming 

The  TwiddleNet  system  was  designed  to  run  on  a 
Microsoft  Windows®  Mobile  Operating  System.  This  software 
application  exploits  the  mobile  network  by  utilizing  a 


^  Flickr  -  Online  photo  management  and  sharing  tool. 

2  You  Tube  -  Allows  people  to  easily  upload  and  share  video  clips 
across  the  Internet  through  Web  sites,  mobile  devices,  blogs,  and  email. 


14 


"push/pull"  technology^  of  data  distribution.  The  user  will 
gather  all  data  and  information  and  while  maintaining  full 
control,  will  distribute  to  all  eligible  recipients.  Users 
can  control  or  specify  the  eligibility  of  recipients 
directly  on  their  personal  handheld  device. 

The  metadata  sent  is  specifically  characterized  at 
creation,  which  significantly  reduces  network  load  and 
increases  network  capacity  and  speed.  Each  recipient  is 
given  an  alert  upon  receipt  of  the  metadata,  both  auditory 
and  visual.  Recipients  can  then  choose  to  download  the  data 
file  instantaneously  on  their  personal  handheld  device,  or 
at  a  more  convenient  time. 

The  TwiddleNet  system  is  comprised  of  ten  components 
[2],  as  depicted  in  Figure  1. 


2  Push:  A  data  distribution  technology  in  which  selected  data  are 
automatically  delivered  into  the  user's  computer  at  prescribed  intervals 
or  based  on  some  event  that  occurs.  Pull:  The  user  specifically  asks  for 
something  by  performing  a  search  or  requesting  an  existing  report,  video 
or  other  data  type.  Browsing  the  Web  is  an  example  of  the  pull  model. 
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Figure  1 .  TwiddleNet  Components 


a.  Content  Creation 

In  the  cyber  realm,  content  can  be  depicted  as  any 
form  of  communication  by  the  smartphone,  i.e.,  text,  photo, 
video,  or  attached  file.  The  content  is  created  by  the 
user,  tagged  accordingly  and  then  manually  or  automatically 
shared . 


b .  Tagging 

Tagging  of  the  content  is  automatic,  consisting  of 
the  user/creator  name,  date  and  timestamp,  file  name,  file 
size,  and  location  (if  GPS  activated) .  Tagging  of  the  data 
created  acts  as  a  record  that  is  stored  within  the  device's 
memory,  as  well  as  the  database  as  Extensible  Markup 
Language  (XML)  documents,  so  that  distribution  within  the 
network  can  simultaneously  occur. 
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c.  Network 

The  TwiddleNet  system  uses  WiFi  or  GSM,  which  are 
both  Internet  Protocol  (IP)  driven.  Each  piece  of  system 
hardware  must  have  its  own  dedicated  Internet  routable  IP 
address  to  properly  send  and  receive  all  metadata  within  the 
WiFi  cloud. 

The  WiFi  cloud  can  be  a  local  network,  generated 
by  the  Network  Operation  Center  (NOC)  ,  subcomponent  of  the 
Joint  Operation  Command  and  Control  (JOCC)  center,  where  a 
specific  block  of  IP  addresses  are  dedicated  to  the  system. 
Or,  the  deployed  TwiddleNet  system  can  generate  a  private 
WiFi  cloud  in  which  to  operate  securely  and  autonomously. 
This  "mobile"  WiFi  cloud  will  be  thoroughly  explained  later 
in  Chapter  IV. 

d.  Database 

The  system  infrastructure  utilizes  a  relational 
database.  The  database  stores  all  metadata  and  their  tags. 
The  smart  caching  is  executed  utilizing  database  tables. 

e.  Smart  Cache 

As  users  create  their  data,  multiple  copies  of  the 
original  data  is  "smart  cached"  or  stored  within  the 
database  utilizing  proxy  servers  for  future  retrieval.  This 
eliminates  an  overload  within  the  network  by  sharing  the 
workload  over  several  servers  thereby  reducing  the  traffic 
within  the  network  so  that  cached  copies  can  be  utilized  to 
service  multiple  user  retrieval  requests. 
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f.  User  Accounts 

Each  handheld  device  requires  the  user  to  log  in 
with  specific  user  name  identifications  (ID),  which  consist 
of  the  team  member  name  and  number,  and  it  is  then 
incorporated  into  the  content  tag.  This  allows  the  system 
translation  scheme  to  seamlessly  track  all  IP  addresses  and 
username  ID  for  metadata  storage,  dissemination  and 
retrieval . 

g.  Metadata  Dissemination 

The  TwiddleNet  system  utilizes  a  single  main 
network  distribution  device  called  the  Portal.  The  Portal, 
which  will  be  explained  in  depth  in  Chapter  III,  receives 
all  metadata  from  all  users  and  instantaneously  disseminates 
the  data  to  all  specified  recipients  operating  within  the 
WiFi  cloud.  The  actual  content  sharing  is  done  by  Hypertext 
Transfer  Protocol  (HTTP)  to  ensure  compatibility  between  Web 
browsers  [ 2 ] . 

h.  Online  Search 

When  a  user  or  team  member  must  search  for  a 
specific  data  file  at  a  later  time,  it  can  be  accessed  via 
the  portal  through  a  Web  browser  based  application.  This 
allows  online  searching  for  data  retrieval.  Additionally, 
user  can  also  retrieve  files  from  the  Portal  via  the 
handheld  device  or  "Client"  application  that  operates 
directly  on  the  smartphone.  Both  alternatives  allow  the 
user  to  do  a  query  text  search  for  categories  specifying 
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"Keyword,"  "Group,"  or  "Author."  The  result  of  each  query 
must  be  "pulled"  and  downloaded  by  the  user  in  order  to  view 
its  content. 

i.  Security  Protocol 

In  present  day  society,  security  of  private 
information  remains  the  utmost  importance  regardless  of  the 
situation.  When  deployed  for  Humanitarian  Assistance 
Disaster  Response  (HADR) ,  TwiddleNet  team  members  will  have 
purview  of  personal  details  that  must  be  safeguarded  within 
the  TwiddleNet  system.  To  accomplish  this,  the  TwiddleNet 
application  utilizes  the  security  features  of  the 
smartphone.  This  includes  incorporating  a  Wired  Equivalent 
Privacy  (WEP)  and  WiEi  Protected  Access  with  Pre-Shared  Key 
(WPA-PSK)  using  the  Temporal  Key  Integrity  Protocol  (TKIP) 
for  data  encryption.  Additionally,  for  the  GSM  domain,  the 
security  of  General  Packet  Radio  Service  (GPRS)  is  exploited 
for  data  transfer  protocol.  At  this  time,  the  current 
TwiddleNet  application  does  not  have  the  individual  ability 
for  confidentiality,  integrity  or  authentication  protocols. 

j.  TwiddleNet  Toolbox 

The  TwiddleNet  Toolbox  consists  of  the  specialized 
system  component  called  the  "Command  Post,"  which  will  be 
explained  in  detail  in  Chapter  III. 

C .  FIRST  ITERATION 

As  mentioned  earlier,  the  genesis  of  TwiddleNet  was 
accomplished  by  two  NPS  students,  Christopher  T.  Clotfelter 
and  Jonathon  E.  Towle  [1]  .  As  a  premise  to  the  TwiddleNet 
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inception,  they  found  that  each  deployed  unit,  i.e., 
medical,  military,  law  enforcement  or  firefighters,  had  to 
transport  several  different  types  of  photographic  apparatus, 
communication  equipment,  electronic  components,  multiple 
power  sources  and  other  miscellaneous  bulky  items  in  order 
to  obtain  a  rapid  and  detailed  picture  for  complete 
situation  awareness.  This  recognition  spawned  the  notion 
that  there  was  a  significant  need  to  streamline  the  process 
of  gathering  and  disseminating  real-time  information  out  in 
the  "field";  i.e..  Battlefield,  Disaster  Field,  etc. 

Additionally,  in  those  areas  affected  by  natural  and/or 
manmade  disaster,  it  is  more  common  than  not  to  lack  basic 
essentials  crucial  to  a  viable  communication  network. 

Necessities,  such  as  shelter,  power,  and  WiFi  capabilities 
are  absent,  especially  in  areas  of  natural  disaster.  The 
need  for  Hastily  Formed  Networks  (HFN)  [3]  was  clearly 
evidenced  by  such  impetus  from  recent  historical  events  like 
9-11,  Hurricane  Katrina  and  the  Indian  Ocean  earthquake 
causing  the  2004  Asian  Tsunami.  The  severity  of  these 
events,  and  many  others  like  them,  had  proven  the  importance 
of  a  strong,  reliable  and  quality  network  system  to  aide  in 
humanitarian  assistance  and  disaster  relief  efforts.  The 
need  for  the  ability  to  create  a  usable  "on-the-fly"  network 
to  gather  and  share  information  was  the  catalyst  for 
TwiddleNet . 

By  harnessing  the  mobile  intelligence  and  power  of 
smartphones,  the  first  iteration  of  TwiddleNet  was  created 
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in  2007,  with  Clodfelter  and  Towle's  research  focusing  on 
the  "Metadata  Tagging  and  Data  Dissemination  in  Mobile 
Device  Networks."  [1] . 

According  to  [1],  Clodfelter  and  Towle  exploited  the 
supremacy  of  these  handheld  devices  to  instantly  capture  and 
disseminate  data  while  commanding  full  control  of  all 
content,  making  it  accessible  to  anyone  with  prior  approval. 

Through  a  combination  of  automatically  generated 
and  user  input  metadata  tag  values,  TwiddleNet 
users  can  locate  files  across  participating 
devices.  Metaphor  appropriate  custom  tags  can  be 
added  as  needed  to  insure  efficient,  rich  and 
successful  file  searches.  Intelligent  data 
dissemination  algorithms  provide  context 
sensitive  governance  to  the  file  transfer  scheme. 

Smart  dissemination  reconciles  device  and 
operational  states  with  the  amount  of  requested 
data  and  content  to  send,  enabling  providers  to 
meet  their  most  pressing  needs,  whether  that  is 
continuing  to  generate  content  or  servicing 
request  [ 1 ] . 

The  key  development  architectural  scheme  of  TwiddleNet 
First  Generation  was  a  type  of  file  sharing  model  or  Server- 
Client  model;  this  produced  a  successful  peer-to-peer  file¬ 
sharing  network.'^  Within  this  centralized  sharing  network, 
the  Portal  tracks  all  data  files  and  images  in  the  database, 
acting  as  a  centralized  gateway  to  all  systemic  nodes, 
recipients  and  data  warehouses  for  the  shared  information. 


Peer-to-Peer  Network:  A  peer-to-peer  computer  network  architecture 
is  an  architecture  in  which  each  node  has  the  same  capabilities  and 
either  node  can  initiate  a  communication  session.  This  technology  is 
typically  used  for  connecting  nodes  via  largely  ad  hoc  connections. 
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1. 


Pros 


Successful  testing  of  First  Generation  TwiddleNet 
comprised  of  capturing  and  disseminating  data  to  all  users 
and  recipients  in  the  controlled  environment  of  the  NFS 
TwiddleNet  TwiddleNet  Lab.  All  TwiddleNet  hardware 
components  associated  to  the  local  NFS  WiFi  lab  and  to  each 
other,  creating  a  strong  social  network.  Generated  photos 
were  clear,  tagging  of  each  photo  was  accomplished,  and 
dissemination  of  the  data  in  real-time  was  successful. 

2 .  Cons 

Although  brilliant  in  concept,  the  First  Generation 
TwiddleNet  had  fundamental  issues  that  caused  instability  in 
network  connectivity  among  primary  TwiddleNet  hardware 
components  like  the  Fortal  and  Handheld  Clients  (For 
thorough  description  of  TwiddleNet  hardware  components,  see 
Chapter  III.)  This  continuing  issue  had  cascading 
repercussions,  causing  handheld  clients  to  be  frequently 
dropped  or  disconnected  from  the  network,  leading  to 
captured  content  never  reaching  intended  recipients. 

Additionally,  the  range  and  battery  life  of  the  basic 
components  were  less  than  desirable.  The  handheld  clients 
could  not  travel  very  far  from  the  portal  due  to  the 
instability  of  the  network  signal.  The  battery  life  of  the 
handheld  clients  were  less  than  optimal,  lasting  at  best  20 
minutes,  which  I  could  only  surmise  was  due  to  the 
inefficiencies/redundancies  of  the  program,  coupled  with  the 
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large  size  of  data  being  captured  causing  reduction  in 
bandwidth  which  also  drained  battery  life  at  an  exponential 
rate . 

D .  SECOND  ITERATION 

The  Second  Generation  TwiddleNet  (2008)  expanded  the 
First  Generation  by  another  NFS  student,  Antonios  Rimikis, 
directing  his  research  on  creating,  "A  Lightweight 
TwiddleNet  Portal,"  [4].  This  thesis  involved  leveraging 
the  capabilities  of, 

...mobile  personal  members,  mobile  social  networks 
and  media  sharing  models  and  developing  a 
TwiddleNet  portal  running  on  a  smartphone  or  PDA 
so  that  the  entire  TwiddleNet  system  can  be  run 
on  handheld  devices  for  rapid  deployment  in 
emergencies  [4]  . 

1 .  Pros 

The  ability  for  a  single  TwiddleNet  Handheld  Device  or 
Client  to  function  as  the  "Portal"  allows  for  complete 
mobility  and  autonomy  of  the  deployed  system. 

2 .  Cons 

There  were  several  concerning  issues  with  this 
iteration  that  occurred  during  lab  and  off  site  deployment 
of  the  system.  These  issues  are  listed  under  Operational 
and  Design  categories. 

a.  Operational 

(1)  After  every  attempt  to  download  an  image,  the 
system  would  freeze,  calling  for  a  constant  reset  of  the 
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handheld  device  and  re-association  into  the  system.  This 
was  a  serious  degradation  of  the  quick  and  real-time 
dissemination  of  captured  data. 

(2)  The  specific  TwiddleNet  Client  with  the  dual 
activity  of  "Portal"  could  not  continue  to  "gateway"  any 
other  information  from  other  handheld  devices  until  the 
error  from  the  malfunctioning  client  had  been  corrected. 
This  was  also  a  major  factor  in  degradation  of  the  system. 

(3)  There  was  no  reliable  "multithreading" 
application  available.  Team  members  were  required  to  wait 
for  the  completion  of  each  sharing  cycle  prior  to  beginning 
a  new  one . 

(4)  Team  members  had  to  stay  within  close 
proximity  of  the  handheld  device  with  the  dual 
responsibility  of  "Portal"  to  maintain  connectivity  to 
ensure  data  reached  the  portal  for  proper  dissemination. 
Built-in  antennas  within  the  smartphones  limited  perimeter 
distance  that  the  team  members  could  loiter  away  from  the 
Portal . 

(5)  The  TwiddleNet-Client/Portal  would  drain 
battery  much  faster  and  therefore  had  to  be  continually 
charged  or  kept  close  to  a  power  source,  which  also  hampered 
perimeter  distance  of  team  members. 

b.  Design 

(1)  After  unexpected  disconnection  from  the 
system  or  interrupted  connectivity  from  the  portal,  the  team 
member' s  collected  data  would  not  be  collected  and  therefore 
storage  to  the  database  could  not  occur. 
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(2)  There  was  a  very  noticeable  time  delay  for 
the  TwiddleNet  Client/Portal  database  to  receive  any  shared 
data.  It  was  confirmed  [by  Rimikis]  that  the  best  solution 
to  eliminate  this  error  was  to  employ  a  dedicated  server  to 
continually  run  in  the  background. 

E .  THIRD  ITERATION 

The  Third  Generation  TwiddleNet  was  created  by  Dirk 
Ableiter  (2008),  directing  his  study  on  the  smart  caching 
portion  of  the  TwiddleNet  program,  specifically  "Smart 
Caching  for  Efficient  Information  Sharing  in  Distributed 
Information  Systems,"  [2].  His  thesis  specifically  detailed 
solutions  to  the  combined  issues  of, 

...Consumers'  demands  to  share  information  showing 
the  need  for  utilizing  the  mobile  devices  more 
efficiently...  This  thesis  offers  an  algorithm 
that  will  conserve  battery  power  and  bandwidth, 
depending  on  demand  and  device  capabilities...  the 
algorithm  will  select  the  content  that  will  most 
efficiently  relieve  these  two  resources  and 
temporarily  upload  it  to  a  proxy  server  that  will 
serve  the  content  on  its  behalf.  This  'smart' 
temporary,  caching  will  last  as  long  as  the 
bandwidth  or  battery  level  limits  are  exceeded 
[2]  . 

1 .  Pros 


a.  Operational 

(1)  Photos  and  data  were  successfully  captured 
and  disseminated  to  all  recipients  logged  onto  the 


25 


TwiddleNet  network.  All  data  was  successfully  tagged  by  the 
creator  and  each  recipient  was  able  to  download  data  at 
their  discretion  or  leisure. 

b.  Design 

(1)  The  TwiddleNet  software  application  continues 
to  support  the  advanced,  real-time  secure  file  sharing;  each 
smartphone  able  to  act  as  content  creator  and  retaining  the 
ability  to  directly  serve  user  requests  in  a  peer-to-peer 
fashion.  TwiddleNet  continues  to  function  in  a  streamlined 
manner,  allowing  the  user  to  capture  and  disseminate 
specific  characterizing  metadata,  thereby  reducing  network 
load  considerably.  In  other  words,  if  the  recipient 
actually  desired  to  view  the  file,  the  file  could  then  be 
downloaded  directly  onto  his  or  her  own  personal  handheld 
device  without  threat  of  system  overload  and  possible 
suspension  of  application  during  file  download. 

(2)  Conservation  of  battery  power  and  bandwidth 
were  successfully  achieved,  by  creating  an  algorithm  that 
efficiently  selected  sets  of  data  that  represented  the 
actual  content  and  temporarily  storing  them  on  a  proxy 
server.  The  proxy  server,  serving  the  content  on  behalf  of 
the  creator,  would  invoke  a  "smart  caching,"  [2]  to  store 
the  data  on  the  portal  until  recipients  were  ready  for 
receipt  by  other  team  members.  This  smart  caching  would  take 
over  when  the  battery  life  of  the  TwiddleNet  Client  when  the 
battery  level  reached  34%,  50%,  or  67%  (preset  by  the  user) . 
This  temporary  caching  would  continue  for  as  long  as  the 
handheld  device  was  signed  on  to  the  network.  If  the  device 
was  to  be  recharged  and  the  battery  level  increased,  all  the 
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cached  information  is  automatically  un-cached  and  shared. 
And  as  a  failsafe,  the  handheld  device  is  automatically 
signed  off  of  the  network  when  the  battery  level  falls  below 
30%.  At  this  time,  the  data  that  was  temporarily  stored  or 
"cached"  on  the  portal  was  copied  and  delayed  from  further 
sharing  until  the  user  was  logged  onto  the  network  again. 

(3)  Voice  and  musical  imprints  were  recorded  to 
indicate  when  the  TwiddleNet  Client  is  added  to  the 
TwiddleNet  network,  when  data  was  sent,  and  when  data  was 
received.  The  following  depicted  each  auditory  signal: 

(a)  Handheld  device  added  to  TwiddleNet 

Network:  pre-selected  music. 

(b)  Data  sent:  "Message  sent." 

(c)  Data  received:  "Alert  received." 

(4)  Along  with  auditory  signals,  written 
verification  was  shown  on  the  screen  of  the  handheld  device: 

(a)  Handheld  device  added  to  TwiddleNet 
Network:  'Signed  in'  or  'Signed  out.  ' 

(b)  Data  sent:  'File  sent.  ' 

(c)  Data  received:  'File  received.' 

(5)  A  new  graphical  user  interface  (GUI)^  feature 
was  implemented  to  specialize  in  treatment  during  medical 
triage  operations.  This  GUI  allowed  for  additional  and 
specific  tagging  of  each  "patient"  to  be  added  at  the 
generation  of  the  content.  This  GUI  provided  the  freedom  to 

^  GUI-  Graphical  User  Interface.  A  visual  way  of  interacting  with  a 
computer  using  items  such  as  windows,  icons,  and  menus  used  by  most 
modern  operating  systems. 
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input  basic  patient  information,  i.e.,  name,  ID  number,  age, 
gender,  etc.  by  utilizing  the  touch  screen  keyboard  or 
smartphone  keypad  and  a  series  of  pull  down  menus.  Further 
specification  of  patient  ailment (s)  could  be  depicted  by  a 
separate  screen  presenting  the  image  of  a  body  (front  and 
back)  and  by  utilizing  the  touch  screen,  the  user  could 
indicate  which  body  part(s)  were  injured/affected. 
Additional  tabbed  screens  allowed  for  indication  of  basic 
treatment,  i.e.,  bandage,  splint,  etc  and  what  types  of 
medication,  if  any,  were  administered.  All  information  on 
each  GUI  screen  could  be  keyed  in  by  utilizing  a  combination 
of  the  touch  screen  keyboard,  smartphone  keypad  and/or  pull 
down  menus.  These  GUI  screens  offered  an  extremely  easier 
interaction  between  user  and  smartphone  to  facilitate  and 
enhance  triage  operations  during  any  humanitarian 
assistance/disaster  relief  (HA/DR)  missions. 

2 .  Cons 

Although  this  version  of  the  TwiddleNet  application  is 
very  robust  and  successful  on  many  levels,  there  continue  to 
be  several  converse  issues  present. 

a.  Operational 

When  taken  out  into  the  field,  the  design  of  the 
hp  iPAQ  phones  lacks  the  ruggedized  and  streamlined  features 
that  users  would  find  helpful  and  sometimes  necessary  during 
HA/DR  missions.  These  features  are  listed  but  not  limited 
to : 

(1)  No  ruggedized  case  to  protect  from 
accidental  abuse. 
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coating . 


(2)  No  waterproof  or  water  resistant 


(3)  Hands-free  capability  -  no  attachment 


for  lanyard. 

(4)  Small  viewing  screens. 

(5)  Unable  to  use  touch  screen  with  gloved 
hands  -  must  use  stylus. 

(6)  Unable  to  take  rapid  photos  -  Noticeable 


delay . 


(7)  Built-in  flash  very  small  -  Must  have 
additional  light  source  when  taking  photos  at  dusk  or  in  the 
dark . 


b.  Design 

(1)  The  TwiddleNet  clients  continue  to  'freeze 
up'  and  display  error  messages  when  several  photos  are  taken 
in  quick  succession  and  automatically  uploaded  onto  the 
TwiddleNet  Portal.  At  times,  one  or  more  files  of  captured 
data  would  not  reach  the  portal  and  therefore  would  not  be 
shared  to  awaiting  recipients.  The  only  solution  to  this 
issue  was  to  reset  the  TwiddleNet  Client  and  reconfigure 
back  into  the  TwiddleNet  Network. 

(2)  The  above  design  flaw  uncovered  an  additional 
design  issue  that  involved  the  TwiddleNet  Client's  inability 
to  self-correct  incidences  of  'multi-threading.' 
Specifically,  when  a  TwiddleNet  Client  lost  connectivity 
during  data  capture,  the  original  IP  address  given  to  that 
specific  TwiddleNet  Client  would  still  be  'in  use.' 
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Therefore,  upon  reset  of  the  'frozen'  TwiddleNet-Client ,  the 
server  and  portal  were  unable  to  associate  or  recognize  the 
TwiddleNet-Client  upon  re-associating  back  into  the 
TwiddleNet  Network.  This  error  would  create  an,  'open 
thread'  that  the  TwiddleNet  Portal  would  continually  search 
for  and  therefore  would  never  recognize  the  original 
TwiddleNet  Client  as  logging  back  in.  The  solution  for  this 
flaw  was  based  on  a  coding  issue  that  had  to  be  corrected  at 
the  programming  level. 

F .  CHAPTER  SUMMARY 

The  TwiddleNet  system  came  from  the  realization  that 
field  work  needed  a  more  streamlined  communication  platform 
in  which  to  capture  and  share  data  in  areas  where  no 
communication  infrastructure  existed.  Leveraging  the 
ubiquity  and  power  of  today' s  smartphones  allowed  the 
creation  of  an  autonomous,  self-contained  adhoc  network  that 
allows  the  capturing  and  dissemination  of  field  data  within 
minutes  of  scene  arrival. 

Although  the  first  three  iterations  of  TwiddleNet  were 
plagued  with  various  operational  and  design  issues,  it  has 
allowed  sound  incremental  improvements  that  have  steadily 
paved  the  way  for  the  more  stable  Fourth  Generation 
TwiddleNet . 
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Ill .  DETERMINATION  OF  METRICS  AND  FEASIBILITY  OF 
USE:  FIRST  THREE  ITERATIONS 


A.  OVERVIEW  OF  APPLICABLE  AREAS  OF  USE 

Deploying  a  damage  assessment  system  for  information 
gathering  after  a  disaster  or  in  response  to  a  DoD  operation 
is  imperative  within  the  first  48-72  hours.  Any 
information,  data,  facts  or  knowledge  gathered  during  any 
operation  is  extremely  time  sensitive  and  oftentimes 
cumulatively  relative  to  previous  data.  Distortion  of  these 
facts  caused  by  flawed  data  collection  or  inaccurate 
information  serves  to  only  compound  an  already  confusing  and 
frequently  extremely  volatile  and  dynamic  environment.  And 
with  the  Normative  Decision  Making  Theory®  prescribing  the 
conditions  under  which  leaders  should  make  decisions 
autocratically,  or  with  other  decision  makers,  it  assumes 
the  following:  Individual  decision  are  more  time-effective 
than  group  decisions,  subordinates  are  more  committed  to  a 
decision  if  they  participate  in  its  formulation,  and 
complex/ambiguous  tasks  require  more  information  and 
consultation  for  reaching  high-quality  decisions.  There  is 
no  space  to  accommodate  the  ill  effects  of  faulty  data 
collection,  producing  a  domino  effect  that  would  easily 
contaminate  and  degrade  the  clarity  of  the  knowledge  gained 
after  processing  the  data. 


®  Normative  Decision  Making  Theory-  Proposed  by  the  Austrian-American 
sociologist  Peter  Blau  (1918-2002),  the  Normative  Decision  Making  theory 
prescribes  the  conditions  under  which  leaders  should  make  decisions 
autocratically,  or  in  consultation  with  the  group  members,  or  with  group 
members  fully  participating. 
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Competent  fact  gathering  and  dissemination  in  an 
environment  based  on  collective  reasoning  is  difficult  when 
faced  with  barriers  and  challenges  that  accompany  any 
natural,  accidental,  or  willful  disaster.  Fact  based 
opinion,  devoid  of  preconceived  stereotypes  and  bias  is  what 
is  needed  by  a  successful  command  and  control,  and  this  can 
only  be  achieved  by  specially  trained  first  responder 
personnel  and  intelligence  organizations  that  can  gather  and 
disseminate  appropriate  information  to  the  decision  makers 
of  each  military  mission. 

As  mentioned  earlier  in  this  thesis,  the  primary  use  of 
the  TwiddleNet  application  was  to  harness  the  technological 
power  of  today's  smartphones  and  incorporate  them  as  the 
primary  tool  for  gathering  and  disseminating  information  and 
data  during  the  rapid  formation  of  'on-the-fly'  networks 
when  deployed  for  humanitarian  aide,  disaster  relief,  or 
large  urgent  projects. 

The  ubiquitous  presence  of  today' s  smartphones  are  not 
limited  to  just  telephonic  communication,  but  rather  they 
are  recognized  as  portable  personal  computers  (PCs)  with  a 
variety  of  communication  capabilities.  More  powerful  than 
their  counterparts  a  decade  ago,  the  content  capture  and 
communication  capabilities  have  paved  the  way  to  a  broad 
array  of  new  services.  Aside  from  their  basic  voice,  text, 
and  email  capabilities,  it  is  now  possible  for  these  mobile 
gadgets  to  provide  video  conferencing  and  streaming 
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multimedia.  Further  technical  advances  have  dramatically 
increased  the  picture  quality  and  the  multimedia  message 
service  (MMS)^. 

With  these  multi-media  enhancements,  the  ability  for 
the  TwiddleNet  application  to  be  deployed  for  any  fact 
gathering  or  triage  mission  utilizing  commercial  off-the- 
shelf  (COTS)®  technology  makes  this  system  not  only 
inexpensive  to  obtain  and  maintain,  but  familiar  and  user 
friendly . 

The  TwiddleNet  application  was  designed  to  support  and 
incorporate  the  advanced,  real-time,  file  sharing  in  a 
secure  network  environment;  to  be  deployed  and  create  a  WiFi 
cloud  in  which  to  capture  and  disseminate  valuable 
information  within  the  first  crucial  48-72  hours,  to 
disseminate  data  for  further  processing  by  Command  and 
Control  (C2)  centers  and  support  medical  agencies. 

The  historical  destruction  caused  by  such  disasters  as 
Hurricane  Katrina  is  an  ideal  scenario  in  which  to  exhibit 
the  positive  potential  of  the  TwiddleNet  application  during 
a  humanitarian  assistance  or  disaster  relief  scope.  In  the 
wake  of  Katrina,  the  communication  infrastructure  was 
completely  devastated,  and  there  remained  the  explicit  need 
for  communication  in  order  to  organize  and  synchronize 
relief  efforts.  The  nature  of  this  scenario  (detailed  in 

Multimedia  Message  Service-  Where  media  messages  are  sent  like  text 
messages  using  the  telephone  infrastructure  or  by  uploading  the  message 
content  onto  Web  pages  using  a  regular  PC. 

®  COTS-  commercial  off-the-shelf.  A  term  for  software  or  hardware, 
generally  technology  or  computer  products,  that  are  ready-made  and 
available  for  sale,  lease,  or  license  to  the  general  public.  They  are 
often  used  as  alternatives  to  in-house  developments  or  one-off 
government-funded  developments. 
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Chapter  VI:  Scenario/Experimentation  and  Results)  permitted 
the  TwiddleNet  application  to  deploy  as  a  Mobile  Emergency 
Command  Post  to  create  an  autonomous  WiFi  network  within  the 
affected  area,  collecting  environmental  data  and  medical 
information  during  the  triage  of  survivors,  and  further 
information  dissemination  to  the  C2  center. 

In  addition  to  facilitating  first  response  and  disaster 
relief,  the  TwiddleNet  program  can  be  deployed  with  military 
patrol  units  or  surreptitious  "cloak  and  dagger"  fact 
gathering  missions  to  gain  photographic/video  graphic  data 
for  dissemination  to  the  C2,  thus  providing  basic 
situational  awareness  of  the  target  individual (s)  or  area. 
Due  to  the  ubiquitous  and  international  existence  of  the 
many  styles  of  the  smartphone,  taking  photographs  and  video 
during  a  covert  mission  is  easily  accomplished. 

Only  customized  coding  and  implementation  limit  other 
applications  for  the  TwiddleNet  program,  external  to  the 
DoD.  As  discussed  by  Ableiter  [2],  Social  Networking 
capabilities  to  broadcast  important  and  real-time  events, 
i.e.,  the  birth  of  a  child  and  all  pertinent  details,  to 
family  and  friends,  without  having  to  make  a  number  of 
individual  calls  via  a  single  point  of  contact  or  a  pre¬ 
planned  phone  tree;  eliminating  the  need  to  take  upload 
photos  and  video  to  pre-existing  Web  sites  and  a  later  time 
or  date.  And  beyond  telecommunications,  texts,  and  email, 
TwiddleNet  offers  the  ability  to  disseminate  group  alerts 
for  medical  reasons,  providing  current  and  real-time  updates 
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or  an  expanded  version  of  Twitter^  where  parents  can  follow 
the  events  in  their  children's  lives,  but  within  a  secure 
and  private  network. 

Within  the  commercial  world,  Internet  based  advertising 
has  become  a  forward  marketing  tool.  With  the  utilization 
of  TwiddleNet,  advertisers  could  disseminate  advertising 
specials  to  consumers,  sending  notification  of  real-time 
sale  exclusives  that  would  persuade  the  consumer  to  purchase 
the  sale  item,  or  at  the  very  least,  draw  them  into  the 
advertiser's  retail  venue,  in  the  hopes  of  leading  to  more 
purchases.  The  ease  of  tracking  consumer-purchasing  habits 
and  utilizing  this  information  to  customize  marketing  alert 
messages  should  have  great  appeal  to  today's  commercial 
advertisers,  giving  the  TwiddleNet  program  a  practical  use 
in  the  business  world. 

B.  METRICS  OVERVIEW 

The  objective  of  this  project  was  to  test  all 
iterations  of  the  TwiddleNet  application  after  each 
modification,  to  document  all  system  improvements  and 
deficiencies,  and  to  definitively  confirm  the  validity  and 
usefulness  of  the  application. 

There  were  several  Measures  of  Performance  (MOP) and 
Measures  of  Effectiveness  (MOE)^^  that  were  considered 


^  Twitter-  Twitter  is  a  privately  funded  startup  with  office  in  SoMA 
neighborhood  of  San  Francisco,  CA.  Started  as  a  side  project  in  March 
of  2006,  Twitter  has  grown  into  a  real-time  short  messaging  service  that 
works  over  multiple  networks  and  devices. 

10  MOP-  Measure  of  Performance.  These  are  expressions  of  a 
quantitative  (objective)  "operational"  measure  that  is  a  key  indicator 
of  task  accomplishment. 
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during  the  testing  and  analysis  of  all  four  TwiddleNet 
iterations.  These  measures  were  developed  to  test  the 
TwiddleNet  hardware  and  software  under  various  types  of 
controlled  environments  and  scenarios,  different 
temperatures  and  weather  conditions,  and  a  range  of  handling 
procedures.  This  section  specifies  how  the  TwiddleNet 
performance  data  was  collected  and  analyzed  throughout  my 
thesis  research.  The  overall  assessment  strategy  for 
TwiddleNet  was  to  evaluate  the  Effectiveness,  Suitability, 
and  Mission  Impact  of  the  various  components  under 
physically  demanding  conditions  with  different  network 
configurations . 

Pre-testing  efforts  consisted  of: 

1.  Establishing  a  baseline  assessment  of  the 
TwiddleNet  system  operating  in  the  present  environment. 

2.  Documenting  environmental  data  (humidity, 
temperature,  and  foliage  density) ,  network  radius  and 
uncontrollable  variables  at  the  testing  site  (aka: 
Humanitarian  Assistance  scenario  site) . 

3.  Ensuring  mechanical  setup,  Startup/Boot  and 
correct  operation  of  system  software. 

When  TwiddleNet  Handheld  Clients  were  deployed, 
verification  of  data  successfully  captured  and  disseminated 
among  team  members,  the  TwiddleNet  Command  Post  and  all 
remote  C2  centers  was  conducted.  It  was  also  confirmed  that 


MOE-  Measure  of  Effectiveness.  These  are  epressions  of  a 
qualitative  (subjective)  "operational"  measure  that  is  a  key  indicator 
of  task  accomplishment. 
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all  TwiddleNet  data  and  images  backhauled  to  the  Joint 
Operations  Control  Center  (JOCC)^^  were  continuous  and 
clear . 

Assessment  of  radius  distance  between  TwiddleNet  team 
members  and  the  TwiddleNet  Portal,  TwiddleNet  Portal  and  the 
TwiddleNet  Command  Post,  and  TwiddleNet  team  members  were 
done  to  evaluate  continuous  data  sharing  and  dissemination. 

The  final  stages  of  testing,  in  consideration 
exclusively  of  TwiddleNet  Fourth  Generation  (described  in 
Chapter  IV)  ,  consisted  of  the  "group-sharing"  feature  and 
the  ability  of  the  TwiddleNet  Handheld  Clients  to 
associate/re-associate  into  the  network  once  the  TwiddleNet 
team  member  has  traveled  outside  the  TwiddleNet  Network 
radius . 

This  final  portion  also  included  investigating  the 
effects  of  associated  TwiddleNet  Handheld  Clients  that  are 
in  'sleep  mode'  (not  gathering  data)  in  15-minute 
increments.  Verification  that  the  Handheld  Clients 
continued  to  be  associated  to  the  network,  automatically  re¬ 
associated  back  into  the  network  post  sleep  mode  period,  or 
required  manually  re-association. 

The  TwiddleNet  proof  of  concept  integrated  the 
capturing  and  sharing  of  data  between  all  TwiddleNet 
Handheld  Clients,  the  TwiddleNet  Command  Post  and  all  remote 
network  locations  via  the  TwiddleNet  Portal  distribution. 


JOCC-  Joint  Operations  Control  Center.  A  central  area  that  boasts 
of  rapid  deployment  capabilities,  increased  operational  capability, 
enhanced  situational  awareness,  and  a  comprehensive  view  of  the 
battlespace;  all  designed  into  a  high  performance,  low-risk  system  that 
enable  decision  superiority  at  all  levels,  and  in  all  domains. 
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The  resulting  system  demonstrated  reception  and  display  of 
TwiddleNet  data  at  local  and  remote  C2  centers .  The  main 
objective  of  the  TwiddleNet  testing  team  adhered  to  was  to 
test  the  TwiddleNet  system  in  various  realistic  scenarios 
and  controlled  lab  environments  for  the  determined 
performance  measures  to  evaluate  the  system's  utility  and 
capability  in  an  operational  context. 

Toward  that  end,  measures  and  data  sources  address  the 
Critical  Operational  Issues  (C0Is)i3,  Ob j ectives ,  and 
MOEs/MOPs,  as  well  as  a  data  collection  and  analysis 
approach . 

1 .  Overview 

To  evaluate  the  Effectiveness  and  Suitability  of  the 
TwiddleNet  capability,  testing  gathered  objective  data  from 
equipment  readings  and  subjective  data  in  the  form  of  user 
feedback.  The  Information  Architecture  (lA)  relied  upon 
Data  Collection  spreadsheets.  Computer  Screen  Captures, 
Event  Logs,  and  data  collector  observations  during  the 
Technical  Capability  Assessments  (TCA)  and  Operational 
Capability  Assessments  (OCA)  event. 

During  OCA  events,  TwiddleNet  users  were  asked  to  do 
the  following: 

a.  Set  up  TwiddleNet  system.  Associate  into  local 
network  using  static  IP  addresses. 

COI-  Critical  Operational  Issues:  Phrased  as  a  question  and  must 
be  answered  in  order  to  properly  evaluate  operational  effectiveness,  and 
operational  suitability. 

Objectives-  Statements  that  break  down  the  COI  into  clearly 
defined  manageable  tasks  and  are  developed  to  group  or  organize  the 
measures  need  to  resolve  the  COI . 
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b.  Use  TwiddleNet  Handheld  Clients  to  capture  data 
when  deployed.  Track  data  shared  using  "group  sharing  and 
multiple  streaming"  features. 

c.  TwiddleNet  teams  traveled  to  specified  distances 
to  verify  maximum  distance  and  range  parameters  for  data 
sharing  and  dissemination  to  team  members,  the  TwiddleNet 
Command  Post,  and  the  C2  centers/ JOCC . 

d.  Evaluate  TwiddleNet  Handheld  Clients'  capability 
for  continuous  connectivity  or  automatic  re-association  into 
the  network. 

e.  Review  data  collected  through  various  scenarios 
and  controlled  environments. 

2 .  Data  Management  and  Analysis 

General  data  management  functions  were  distributed 
among  the  members  of  the  TwiddleNet  Team  and  consisted  of 
the  following: 

a.  Identification  of  data  requirements. 

b.  Data  collection. 

c.  Data  reduction  and  analysis. 

d.  Generation  of  analysis  products. 

3 .  Database  Development 

The  TwiddleNet  team  used  standard  commercial  word 
processing,  spreadsheet  and  database  software,  i.e., 
Microsoft  Windows®  Word,  Access  and  Excel,  to  analyze  and 
manage  Computer  and  Event  Log  as  well  as  data  collected 
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during  the  testing  periods.  I  developed  and  maintained  the 
TwiddleNet  master  database  for  data  reduction  and  analysis. 

4 .  Database  Verification 

I  ensured  the  completeness,  accuracy  and  quality  of  the 
data  stored  in  the  TwiddleNet  database.  Each  member  of  the 
TwiddleNet  team  was  responsible  for  reviewing  their  event 
logs  and  test  data,  annotating  the  notes  where  necessary. 
The  data  was  annotated  in  the  database  at  the  conclusion  of 
the  day's  testing  events,  or  as  soon  as  able.  I  reviewed 
the  completed  database  to  ensure  data  accuracy. 

5.  Database  Processing  and  Analysis 

Data  was  entered  directly  into  the  TwiddleNet  database 
whenever  feasible.  Data  collectors  were  trained  in  data 
entry  procedures  and  all  data  were  entered  at  the  end  of 
each  day.  Data  entered  into  or  transferred  to  electronic 
storage  was  backed  up  using  portable  media  devices. 

C .  SYSTEM  ARCHITECTURE 

TwiddleNet  is  a  program  that  exploits  the  power  of 
today's  COTS  smartphones  to  create  mobile  personal  servers 
that  "serve  up"  real  time  information  for  sharing  among 
awaiting  recipients.  This  architecture  employs  various 
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communication  modes,  i.e.,  WiFi,  GSM/CDMA^^,  GSPRS/EDGE^®, 
WiEi  802.11b  and  Bluetooth,  which  are  standard  within  these 
smartphones  to  support  a  rapidly  deployed  adhoc  network  and 
a  dependable  data-sharing  infrastructure. 

The  main  components  of  the  TwiddleNet  architecture  are 
the  Client,  the  Portal,  and  the  Command  Post. 

1 .  Client 

TwiddleNet  system  has  been  utilizing  the  Hewlett- 
Packard  iPAQ  hw  6945  Mobile  Messenger  Smartphone  for  testing 
purposes  (figure  2)  .  The  iPAQ  hw  6945  comes  standard  with 
the  following  specs  [6] : 

a.  Integrated  Antenna. 

b.  Integrated  Quad  band  GSM/BPRS/EDGE  wireless  radio 

with  automatic  band  transition. 

c.  Integrated  GPS  Receiver. 

d.  Integrated  Wi-Ei  (802.11b). 


GSM-  (Global  System  for  Mobile  communications)  is  the  most  popular 
standard  for  mobile  phones  in  the  world.  GSM  is  used  by  over  3  billion 
people  across  more  that  212  countries.  Its  ubiquity  makes  international 
roaming  very  common,  enabling  subscribers  to  use  their  phones  all  over 
the  world.  GSM  differs  from  its  predecessors  in  that  both  signaling  and 
speech  channels  are  digital,  and  thus  is  considered  a  second-generation 
(2G)  mobile  phone  system.  CDMA-  (Code  division  multiple  access)  is  a 
channel  access  method  utilized  by  various  radio  communication 
technologies.  It  employs  spread-spectrum  technology  and  a  special 
coding  scheme  (each  transmitter  is  assigned  a  code)  to  allow  multiple 
users  to  be  multiplexed  over  the  same  physical  channel. 

GPRS-  (General  packet  radio  service)  is  a  packet  oriented  mobile 
data  service  available  to  users  of  the  2G  cellular  communication  systems 
GSM,  as  well  as  in  the  3G  systems.  In  2G  systems,  GPRS  provides  data 
rates  of  56-114  Kbit/s.  EDGE-  (Enhanced  Data  rates  for  GSM  Evolution) 
is  a  backward-compatible  digital  mobile  phone  technology  that  allows 
improved  data  transmission  rates,  as  an  extension  on  top  of  standard 
GSM.  EDGE  is  considered  a  #g  radio  technology  and  is  part  of 
International  Telecommunications  Union's  3G  definition. 
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e.  Integrated  Bluetooth  1.2  wireless  technology. 

f.  Intel  PXA270  Processor  416  MHz. 

g.  Integrated  HP  Photosmart  1.3  MP  Camera. 

h.  Integrated  alphanumeric  keyboard. 

1.  Integrated  miniSD  slot  (memory  only) . 

j.  Removable/rechargeable  1200  mAh  3.7  Volt,  Lithium- 
ion  battery. 

k.  Microsoft  Windows®  Mobile  5.0  for  Pocket  PC,  Phone 
Edition,  with  Messaging  and  Security  Feature  Pack. 

l.  Mobile  versions  of  Microsoft  Windows®  Office 
software  include  (Word,  Excel,  PowerPoint,  and  Internet 
Explorer) . 


Figure  2.  iPAQ  hw  6945  Mobile  Messenger  Smartphone. 


Each  TwiddleNet  team  member  is  given  their  own  HP  iPAQ 
hw  6945  which  utilizes  the  Microsoft  Windows®  Mobile  program 
to  run  the  TwiddleNet  application,  coordinating 
communication  between  all  the  components.  Upon  logging  into 
the  TwiddleNet  network,  each  handheld  device  is  assigned  a 
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specific  and  unique  IP  address  from  the  TwiddleNet  DHCP 
server,  automatically  giving  the  content  creator  a  specific 
tag.  Alternately,  the  TwiddleNet  client  can  also  be 
assigned  a  specific  IP  address  that  can  be  hard  coded  into 
the  smartphone.  This  is  usually  done  when  the  local  adhoc 
network  has  assigned  a  specific  block  of  IP  addresses  for 
the  exclusive  use  by  the  TwiddleNet  team.  All  metadata 
files  are  instantaneously  tagged  with  the  content  creator's 
specific  tag  and  IP  address. 

After  logging  into  the  system,  the  client  has  three 
utilities : 

a.  Allowing  the  TwiddleNet  member  to  instantly  create 
metadata,  capture  images  and  photos  (utilizing  the  1.3  MP 
camera)  and  disseminate  to  the  entire  team. 

b.  Alerting  the  portal  of  immediate  availability. 

c.  Offering  a  basic  interface  for  the  team  member  to 
accept  and  download  any  metadata  files  created  by  other  team 
members . 

All  TwiddleNet  team  members  are  deployed  with  the 
TwiddleNet  Portal  (Figure  3)  to  gather  and  disseminate  data, 
functioning  as  either  personal  content  servers  or  personal 
content  requesters.  This  role  exchange  is  automatic,  easily 
accomplished  and  transparent  to  the  team  member. 
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Client  2 


Client  3 


M 


Client  4 


Figure  3.  Basic  TwiddleNet  Infrastructure  w/handheld 

acting  as  the  Portal. 


2 .  Portal 

For  all  iterations  of  the  TwiddleNet  system,  the  OQO 
Ultra  Mobile  PC  (Figure  4)  has  been  utilized  as  the  main 
Portal  component,  and  the  HP  IPAQ  hw  6945  smartphone  as  an 
alternate  option.  The  OQO  Ultra  Mobile  PC  is  a  fully 
functional  Windows  PC  small  enough  to  fit  in  your  pocket, 
yet  powerful  enough  to  rival  a  regular  laptop.  It  comes 
standard  with  the  following  specifications  [7] : 

a.  OS:  Microsoft  Windows®  XP  Professional. 

b.  IGHz  Transmeta  Crusoe  Processor. 

c.  30GB  hard  drive  (shock-mounted) . 

d.  512MB  DDR  RAM. 
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e.  800  X  480  W-VGA  5" 

(indoor/outdoor  readable). 

transf lective  display 

f . 

3D  accelerated  graphics  with  8MB 

of  video  RAM. 

g- 

802.11b  wireless. 

h . 

Bluetooth  wireless. 

i . 

4-pin  FireWire  (1394) /USB 

2.0. 

j  • 

3.5mm  stereo  headphone  jack/micr 

ophone/ speaker . 

k. 

Battery  life  up  to  three 

hours . 

1. 

Weight:  14  ounces. 

m. 

cable. 

Accessories:  Universal 

desktop  docking  stand. 

power 

supply,  docking 

n . 

For  input /navigation : 

Thumb 

keyboard  with 

TrackStick,  mouse  buttons,  and  thumbwheel. 


Figure  4.  a.  OQO  Ultra  Mobile  PC.  b.  OQO  Ultra  Mobile 

PC  w/Docking  Station. 
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Figure  5 . 


Basic  TwiddleNet  Infrastructure  w/OQO  as  Portal. 


The  TwiddleNet  Portal  (shown  in  Figure  5)  acts  as  a 
type  of  gateway  for  the  TwiddleNet  network,  monitoring  when 
clients  log  in  and  out  of  the  system,  receiving  and  storing 
all  metadata  and  content  generated  by  all  the  users,  and 
disseminating/ "pushing"  to  all  team  members  instantaneously 
or  when  a  user  "pulls"  the  information  at  a  later  time.  The 
Portal  also  stores  all  "tagging"  information  for  all 
TwiddleNet  Clients  logged  into  the  system,  tracking  all  IP 
addresses  currently  in  use. 

3.  Command  Post 


Currently,  the  TwiddleNet  Command  Post  program 
functions  on  a  Linux  laptop,  but  can  be  run  on  any  Windows 
laptop  or  desktop  computer.  When  specified  by  the 
individual  Clients,  the  Command  Post  will  receive  all 
metadata  alerts  and  can  also  retrieve  or  "pull"  all  content 
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files  that  are  being  temporarily  stored  by  the  Portal.  It 
then  displays  all  downloaded  content  on  the  Web  display  page 
in  sequential  order  of  receipt.  Each  data  file  is 
automatically  tagged  by  the  specific  content  creator  and  any 
other  specific  information,  inputted  by  the  user  upon  data 
creation,  is  also  shown.  The  Command  Post  also  has  the 
ability  to  manually  update  each  data  file,  at  any  time,  with 
additional  information  beneath  each  displayed  image. 

The  Command  Post  is  typically  left  at  the  JOCC  or  C2 
location  to  generate  increased  information  superiority. 
Through  Network  Centric  Warfare^’^  [8]  utilities,  the 
deployed  users  can  "push"  data  from  the  affected  area  to 
mission  commanders  to  achieve  shared  awareness  and  a  level 
of  synchronization  for  all  decision-makers. 

Alternatively,  the  Command  Post  can  also  be  deployed 
with  the  TwiddleNet  Clients  and  Portal  to  the  affected  area 
and  be  linked  to  the  J0CC/C2  via  backhaul  link 
communications  or  SATCOM  (satellite  communications ) . 
Regardless  of  whether  the  Command  Post  is  deployed  or  not, 
any  computer  system  operating  within  the  same  WiFi  network 
as  the  TwiddleNet  system  can  access  all  data  and  photos  on 


Network  Centric  Warfare-  A  term  developed  to  describe  the  way  the 
DoD  would  like  to  organize  and  fight  in  the  Information  Age.  The  former 
CNO,  ADM  Jay  Johnson,  has  called  it  "a  fundamental  shift  from  platform¬ 
centric  warfare."  In  essence,  NCW  translates  information  superiority 
into  combat  power  by  effectively  linking  knowledgeable  entities  in  the 
battlespace . 

SATCOM-  Satellite  Communications.  A  family  of  communications 
satellites  originally  developed  and  operated  by  RCA  American 
Communications  (RCA  Americom) [11] .  An  artificial  satellite  that  is  used 
to  help  telecommunication  by  reflecting  or  relaying  signals  back  from 
space  and  back  down  to  Earth.  It  is  the  most  powerful  form  of  radio  and 
it  can  cover  far  more  distance  and  wider  areas  than  other  radios.  It 
can  also  communicate  with  words,  pictures  and  other  forms  of 
information . 
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the  Command  Post  database.  Opening  a  Web  browser  on  the 
specified  computer  and  typing  in  the  IP  address  of  the 
TwiddleNet  Command  Post  laptop  will  accomplish  this.  Figure 
6  is  a  screen  capture  of  the  TwiddleNet  Command  Post 
display.  Note  that  basic  information  of  the  photo  is 
displayed  just  underneath  the  captured  image. 


O  TwiddleNet  Commend  Post  -  Windows  Internet  EHplorer 
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Figure  6.  TwiddleNet  Command  Center  screen  display. 


D.  NEWLY  DESIGNED  DATABASE 

The  newly  designed  Portal  Database  was  created  by  LCDR 
Todd  Glidden  [4]  and  is  featured  in  the  4th  iteration  and 
fully  described  in  Chapter  IV.  Critical  to  the  TwiddleNet 
program  design,  the  Portal  Database  warehouses  system  data, 
to  include  user  identification,  device  and  component  data. 
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IP  addresses,  temporarily  stored  metadata,  and  group 
membership  classifications.  Because  of  continued  errors 
with  multithreading,  group  sharing,  and  associated  issues 
with  network  congestion,  Glidden  recognized  the  need  to 
upgrade  the  Portal  Database  design. 

Glidden  re-constructed  the  database  design,  utilizing 
formal  database  design  methods,  to  include  Entity- 
Relationship  (E-R)  and  Relational  modeling.  The  major 
elements  of  the  new  database  are  [9]  : 

1.  Portal  User  Table.  This  contains  user 
identification  that  is  critical  for  verification  when  the 
user  signs  in  and  for  linking  users  to  groups  (to  track 
group  membership) .  This  element  is  fundamental  to  the  user¬ 
partitioning  feature  introduced  in  the  4th  iteration. 

2.  Belongs  To  Table.  Routes  users  to  groups  by 
linking  a  unique  user  identifier  listed  in  the  Portal  Users 
Table  with  a  unique  group  identifier  stored  in  the  Groups 
Table.  This  tells  the  Portal  which  users  belong  to  which 
groups  so  that  alerts  and  data  dissemination  can  be  properly 
sent  to  the  specified  group (s). 

3.  Groups  Table.  This  links  the  user  with  his 
specific  handheld  device.  This  is  accomplished  by  linking  a 
unique  identifier  for  the  user  from  the  Portal  Users  Table 
with  a  device  identifier  in  the  Devices  Table.  The  IP 
address  of  the  user's  device  is  stored  and  can  be  retrieved 
by  the  Portal  from  the  Devices  Table. 

4.  Devices  Table.  Stores  critical  identification 
information,  to  include  IP  addresses,  for  all  handheld 
devices  signed  onto  the  TwiddleNet  system. 
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5.  Content  Info  Table.  Stores  the  metadata 
associated  with  shared  data/inf ormation . 

6.  Special  Tags  Table.  This  is  designated  to  store 
situation-specific  data,  as  established  by  the  system 
administrators  and  mission  planners  deploying  the  TwiddleNet 
system.  Currently,  this  table  stores  medical  triage  data  as 
detailed  in  [ 2 ] . 

The  database  management  system  used  for  this  upgrade 
was  MySQL.  As  specified  by  Glidden,  the  decision  to  use 
MySQL  was  based  on  the  following: 

1.  It  is  an  open-source  and  freely  available. 

2.  It  allows  for  easy  administration  through  the  use  of 
tools  such  as  phpMyAdmin^s  [10]  . 

As  detailed  in  the  System  Qperation  (Chapter  IV)  the 
MySQL  must  be  activated  during  the  sign-in  process  of  the 
Portal  to  begin  the  gateway  functions. 


PhpMyAdmin-  An  open  source  tool  written  in  PHP  intended  to  handle 
the  administration  of  MySQL  over  the  World  Wide  Web.  It  can  perform 
various  tasks  such  as  creating,  modifying  or  deleting  databases,  tables, 
fields  or  rows;  executing  SQL  statements;  or  managing  users  and 
permissions . 
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IV.  FOURTH  ITERATION 


A.  OVERVIEW  OF  OLD  AND  NEW  TWIDDLENET  OPERATION 

In  previous  iterations  of  TwiddleNet,  the  users  or 
content  creators  were  all  members  of  the  same  group  or  team; 
users  were  defined  and  delineated  only  by  their 
identification  tags.  However,  in  the  fourth  iteration  or 
Fourth  Generation  TwiddleNet,  Glidden  expanded  the 
TwiddleNet  virtualization  operation  to  include  a  group 
partitioning  application  and  content  privacy.  Through  his 
research  and  coding  development,  Glidden  presents  in  his 
thesis,  "Privacy  for  Mobile  Networks  via  Network 
Virtualization [9]  : 

The  use  of  mobile  devices  and  mobile  networks  to 
[define  and  expand]  a  network  virtualization 
technique  in  order  to  provide  content  privacy 
protection.  This  allows  TwiddleNet  users  to 
share  content  on  a  per-group  basis  among  virtual 
networks  of  user  groups.  It  was  found  that  this 
virtualization  technique  successfully  provided 
content  privacy  protection  from  the  threat  of  a 
casual  observer  [9]  . 
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Figure  7.  Old  TwiddleNet  Operation. 


Figure  7  illustrates  the  old  operational  layout  of 
TwiddleNet  Generation ( s )  1-3,  utilizing  the  local  adhoc  WiFi 
802.11b  network  generated  by  the  mission  C2/JOCC.  As  shown 
here,  all  TwiddleNet  clients  are  functioning  within  one 
group  construct,  sharing  all  information  among  all  team 
members  and  the  Command  Post  via  the  OQO  Portal.  (Note: 
When  operating  within  the  02  adhoc  WiFi  network,  pre¬ 
ordained  static  IP  addresses  are  set  aside  for  the  explicit 
use  of  the  TwiddleNet  Team(s)  .  All  IP  addresses  are  hard 
coded  into  each  component,  with  the  Command  Post  and  Portal 
always  programmed  with  the  first  two  addresses.) 
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Figure  8.  New  TwiddleNet  System  Operation  w/Group 

Partitioning . 

As  Figure  8  illustrates,  each  content  creator  is  a 

member  of  a  specific  group:  Team  1  (a/b) ,  2  (a/b) ,  or  3  (a/b)  . 

This  is  chosen  upon  sign  in  of  that  particular  handheld 

client.  Team  members  can  specify  which  team(s)  will  be  a 

recipient  (s)  of  their  metadata  to  include  the  Command  Post. 

For  example,  if  Team  la  member (s)  desire  to  share  content 

only  with  members  of  Team  3b  and  the  Command  Post,  these 

recipients  would  be  chosen  during  the  sign  in  process.  When 

Team  la  members  create  their  metadata,  it  is  sent  to  the 

Portal,  which  sends  alerts  and  shares  the  data  with  only 

Team  3b  members  and  the  Command  Post;  the  other  Teams  are 
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not  alerted  and  therefore  will  not  have  access  to  the 
information.  After  receiving  an  alert,  the  recipient  (s)  may 
download  the  file  instantaneously  or  at  a  later  time. 

Furthermore,  if  a  Team  la  user(s)  desires  to  change 
recipients  during  exploration  and  data  collection,  this  can 
be  accomplished  by  returning  to  the  "Recipient  Options" 
screen  without  requiring  signing  out  and/or  signing  in.  The 
upgrade  in  the  Portal  Database  allows  this  streamlined  group 
partitioning  to  function  smoothly  and  seamlessly,  the  user 
simply  making  use  of  a  basic  GUI  (Figure  9)  ,  selecting  the 
box  of  specified  recipient  (s)  with  the  stylus  and  touch 
screen.  The  default  box  is  always  the  team  that  the  user 
belongs  to.  For  added  convenience,  there  are  also  two  other 
boxes  labeled  "All"  or  "None." 

Within  the  user-partitioning  feature,  teams  are 
explicitly  labeled  as: 


1. 

Team  1 (a 

)  (b)- 

Medics . 

2. 

Team  2 (a 

)  (b)- 

Fire  Fighters. 

3. 

Team  3 (a 

)  (b)- 

Police . 

4. 

Command 

Post . 

54 


SystemSetu  p  Form 


Figure  9.  TwiddleNet  Client  Recipient  Options  screen. 

There  is  no  limit  to  the  number  of  handheld 
clients/users  within  each  team. 

The  second  noteworthy  advance  in  Fourth  Generation 
TwiddleNet  is  the  content  privacy  stemming  from  the  user¬ 
partitioning  feature.  With  the  ability  to  specify  which 
team  members  can  receive  the  information,  safeguards  the 
information  collected.  For  example,  members  within  the 
Medics  Team  will  be  collecting  personal  patient  information, 
i.e..  Name,  age,  identif ication/SS  number,  etc.  that  does 
not  need  to  be  shared  with  members  of  the  Fire  Fighter  and 
Police  team.  Concurrently,  Medic  team  members  would  not 
find  it  necessary  to  know  of  any  illegal  proceedings,  i.e., 
looting/burglary,  going  on  in  a  different  part  of  the 
affected  area. 

The  third  noteworthy  advance  within  Fourth  Generation 
TwiddleNet  is  the  advent  of  the  TwiddleNet  Gateway 
component.  The  TwiddleNet  Gateway  was  a  piece  of  new 
interfacing  software,  placed  on  a  separate  Dell  laptop, 
which  allowed  content  sharing  and  receipt  from  other 
external  sources,  i.e.,  the  Command  Post.  The  Gateway  could 
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also  "push"  data  and  information  to  all  the  TwiddleNet 


users,  utilizing  the  same  group-partitioning  feature, 
specifying  who  would  receive  the  information.  The 
TwiddleNet  Gateway  could  be  as  close  as  within  the  mission 
J0CC/C2,  or  as  far  away  as  a  different  city,  state,  or 
country.  In  these  instances,  connectivity  would  have  to  be 
generated  by  SATCOM. 
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Figure  10.  Advanced  TwiddleNet  Layout  w/SATCOM  and  Gateway. 


Figure  6  shows  the  advanced  layout  of  the  TwiddleNet 

system  during  a  complex  operation.  Within  several  WiFi 

adhoc  networks  generated  by  several  access  points,  several 

TwiddleNet  teams  are  deployed  into  the  affected  area(s) 

(i.e.,  Thailand,  New  Orleans),  generating  and  gathering  data 
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that  is  sent  to  the  deployed  TwiddleNet  Portal,  which  in 
turn,  sends  alerts  to  the  other  team  members  and  to  the 
command  post.  Each  JOCC  and  external  Gateway  site  (i.e., 
NFS-  Naval  Postgraduate  School)  can  access  all  data  sent  to 
and  from  the  command  post  via  connections  generated  by 
backhaul  links  and  SATCOM,  providing  far-reaching 
capabilities  anywhere  in  the  world. 

1 .  Implementation  Tools 

The  software  programming  language  used  for  all  the 
TwiddleNet  iterations  was  C# .  The  TwiddleNet  Portal  code  is 
based  on  the  .NET  2.0  Eramework  intended  for  PC  integration. 
The  TwiddleNet  Client  coding  is  the  Pocket  PC  application, 
supported  by  the  .NET  2.0  Compact  Eramework,  intended  for 
use  by  devices  running  Windows  Mobile  5  operating  system 
(OS)  . 

Microsoft  Windows®  Visual  Studio  2005  Integrated 
Development  Environment®  was  employed  during  the  TwiddleNet 
program  development.  This  was  due  to  the  ease  of  use, 
translation  and  integration  for  the  C#  language, 
furthermore.  Visual  Studio  was  an  excellent  integration  tool 
with  the  Pocket  PC  Software  Development  Kit,  providing  a 
powerful  standard  for  the  Client  development,  offering 
additional  tools  for  easy  code  transference  and  device 
testing . 

As  mentioned  earlier,  MySQL  Database  Management  System 
was  utilized  to  accommodate  the  TwiddleNet  Portal  database 
(refer  to  Chapter  III,  pg.  46)  .  This  management  system 
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incorporated  the  XAMPP^o  cross-platform  Web  server  for  ease 
of  implementation  and  testing.  It  also  allowed  the  use  of 
phpMyAdmin  for  a  convenient  interface  for  the  MySQL 
database,  resulting  in  a  simplified  management  tool  for  the 
TwiddleNet  Portal  database. 

2 .  Fly  Away  Kit 

With  all  iterations  of  TwiddleNet,  the  consistent  theme 
was  the  ability  to  be  quickly  deployed  and  easily 
established  with  efficient  ease.  With  this  in  mind,  the 
creation  of  the  TwiddleNet  Fly  Away  Kit  (FLAK)  was 
accomplished  and  perfected.  With  the  simple  addition  of  a 
COTS  Cisco  Aironet  Wireless  Access  Point  (Figure  11),  the 
TwiddleNet  System  became  completely  autonomous;  capable  of 
deploying,  creating  a  private  and  encrypted  WiFi  network, 
and  gathering  and  disseminating  information  within  20 
minutes  of  on-site  arrival  (thoroughly  explained  in  Chapter 
VI:  Experimentation  and  Results) .  The  TwiddleNet  Access 
Point  transmits  802.11a/b/g,  and  is  designated  as  the 
TwiddleNet  Mobile  Network. 


XAMPP-  A  free  and  open  source  cross-platform  Web  server  package, 
consisting  primarily  of  the  Apache  HTTP  Server,  MySQL,  and  also 
translates  code  written  in  the  PHP  and  Perl  program  languages.  It  is 
designed  to  allow  programmers  to  test  work  on  their  own  computers 
without  Internet  access. 
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Figure  11.  Cisco  Aironet  Wireless  Access  Point. 

The  TwiddleNet  FLAK,  encased  in  a  single,  medium  sized, 
portable  Pelican  Case  Product^i,  stores  and  protects  the 
following  TwiddleNet  hardware  components: 

1.  10  Clients  (w/desktop  charging  stations  and  power 
cords) . 

2.  1  OQO  Ultra  Mobile  PC  (w/desktop  charging  station 
and  power  cord) . 

3.  1  Linux  laptop  and  power  cord  (Command  Post) . 

4.  1  Dell  laptop  and  power  cord  (Gateway) . 

5.  1  Cisco  Wireless  Access  Point  (w/power  cord  and  4' 
CAT  5  cable) . 

6.  4  8-outlet  surge  protectors/power  strips. 

The  Pelican  Case  (pictured  in  Figure  12)  is  tactical, 
logistical  and  durable,  airline  and  Transportation  Security 
Administration  (TSA)  approved,  making  this  an  ideal 


Pelican  Case  Products-  Pelican  Products  is  a  global  manufacturer 
of  advanced  lighting  system,  rugged  protector  cases  and  shipping 
containers 
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transport  container.  All  components  are  110v/220v 

compatible,  allowing  deployment  to  other  countries  possible. 


Figure  12.  Pelican  Case  w/Customizing  Padding. 


B.  NEW  TWIDDLENET  SYSTEM  OPERATION  AND  SETUP  PROCEDURES 


This  section  provides  a  step-by-step  guide  for  the 
complete  preparation  and  implementation  of  the  TwiddleNet 
System.  With  this  complete  and  detailed  guide,  training  of 
any  new  user  could  be  accomplished  within  one  hour. 


1 .  Create  the  WiFi  Cloud 


a.  Plug  in  and  power  up  the  Linux  laptop/Command 

Post . 

b.  Connect  the  TwiddleNet  Cisco  Wireless  Access  Point 
with  the  blue  CAT  5  cable. 

c.  Connect  the  TwiddleNet  Access  Point  power  cord 
into  the  surge  protector/power  strip. 


2 .  Setup  of  the  Portal 


a.  Plug  in  and  power  up  the  OQO  Mobile  PC. 
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b.  Ensure  that  it  is  connected  to  the  TwiddleNet 
Mobile  Network  and  is  assigned  the  following  IP  address: 

192.168.1.3. 

c.  Scroll  to  the  bottom  icon  "XAMP." 

(1)  Start  "XAMP." 

d.  Double  click  on  the  TwiddleNetServer  icon. 

(1)  A  command  window  pops  up  and  states  that  the 
server  is  running. 

(2)  If  this  does  not  occur,  verify  WiFi 

connection  and  then  double  click  the  TwiddleNetServer  icon. 

3.  Command  Post  Setup 

a.  Verify  that  the  Portal  (OQO  or  client)  IP  Address, 
within  the  TwiddleNet  Mobile  Network,  is  listed  as: 

196.168.1.3. 

b.  Double  click  on  the  Command  Post  icon. 

(1)  The  Command  Post  screen  will  display. 

(2)  Press  the  "Start"  button  at  the  bottom  of  the 
screen  only  once. 

(3)  The  screen  should  display  "Waiting  for 

alerts . " 

c.  Open  the  Internet  Explorer  browser  and  type, 
"www.localhost.8080"  in  the  browser  line  (should 
be  in  the  history  pull  down  menu) . 

(1)  The  displayed  page  is  probably  an  old  page, 
so  once  you  have  taken  a  test  photo,  the  screen  will  refresh 
automatically.  If  not,  press  the  "refresh"  button. 


61 


4. 


Setup  of  the  Client 


NOTE:  Prior  to  the  start  of  any  mobile  device,  ensure 

that  all  other  service  components  are  running  properly. 

a.  Power  up  handheld  device  (power  button  located  on 
top  right  of  smartphone) . 

b.  Verify  association  to  correct  network. 

(1)  Press  the  WiFi  "iPAQ  wireless"  tab. 


Figure  13.  WiFi  iPAQ  wireless  tab  screen. 
(2)  Press  "View  WiFi  Networks." 


Figure  14.  iPAQ  Screen  "View  WiFi  Networks." 

(3)  Click  once  on  the  specific  network  name. 
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Figure  15. 


iPAQ  Configure  Wireless  Networks  screen. 


c.  Adding  a  New  Network  on  the  iPAQ  wireless. 
(1)  Return  to  the  iPAQ  wireless  screen. 


Figure  16.  iPAQ  wireless  tab  screen. 


(2)  Press  "View  WiFi  Networks." 


Figure  17.  iPAQ  "View  WiFi  Networks"  screen. 
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(3) 


Click  once  on  "Add  New. . . 


Figure  1 8 . 


iPAQ  Configure  Wireless  Networks  "Add  New. . . 
screen . 


(4)  Type  in  the  new  Name,  then  click  on  the  tab 
in  the  center  of  the  screen  that  reads  "Network 
Key.  " 


Figure  19.  iPAQ  "Configure  Wireless  Network"  screen  w/Network 

Key  tab. 


(5)  Select  the  appropriate  Authentication  and 
Encryption . 
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Figure  20. 


Figure  2 1 . 
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iPAQ  "Configure  Network  Authentication"  screen, 


(6)  NOTE:  For  "TwiddleNet "  and  "TwiddleNet 

Mobile"  networks,  the  Authentication  is  "Open"  and 
the  Encryption  is  "WEP."  Ensure  that  the  tickbox 
underneath  is  not  selected. 

(a)  Enter  the  network  key  "927e31e9b8"  into 
the  field. 

(b)  Click  "OK"  on  the  top  right  of  the 
screen . 

(c)  If  it  does  not  connect,  try  re-entering 
the  key,  turn  WiFi  off  and  on  again. 


iPAQ  "Configure  Network  Authentication"  screen. 
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d.  If  the  DHCP  (mechanism  that  automatically  assigns 
IP  addresses)  is  provided  by  the  network,  the  Client  should 
now  receive  an  IP  address.  Verify  by  going  to  the  iPAQ 
Wireless  screen  (Figure  22) . 


Figure  22.  iPAQ  Wireless  screen. 


(1)  NOTE:  For  Advanced  Users:  If  you  know  that 

you  do  not  have  DHCP  service,  get  an  IP  address, 
network  mask,  default  Gateway  and  DNS  address  from 
the  Network  Administrator. 


e . 


Return  to  the  main  screen  (Figure  23)  .  Turn  on 
the  WiFi  by  pressing  the  second  grey  button  from 
the  left  only  ONCE. 


Figure  23.  iPAQ  Main  screen. 
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(1)  The  WiFi  button  will  turn  green  once  it  has 


associated  to  the  network  with  an  IP  address. 


(2)  NOTE:  If  it  does  not  turn  green-  check  WiFi 
connection  again. 

(3)  NOTE:  If  it  still  does  not  turn  green- 
verify  that  IP  address  (manual/automatic)  is  correct  for  the 
specific  network  being  used. 


Eigure  24.  iPAQ  Start  menu. 


return  to  the 


g.  Scroll  to  "Program  Files." 

h.  Start  TwiddleNet  program.  (Skip  directly  to 
"Start  TwiddleNet"). 

i.  To  manually  enter  a  Fixed  IP-Address: 

(1)  Go  directly  to  the  iPAQ  Wireless  screen  and 
select  the  "View  WiFi  Networks"  (Figure  25) . 
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Figure  25.  iPAQ  Wireless  screen. 

(2)  On  the  bottom  of  the  screen,  select 
"Network  Adapter"  tab  (Figure  26)  . 


Figure  26.  iPAQ  Configure  Wireless  screen. 

(3)  Click  on  the  WiFi  Adapter  (Figure  27) . 


Figure  27.  iPAQ  Configure  Network  Adapter  screen. 


the 
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II 


and  enter 


(4)  Select  "Use  Specific  IP  Address, 
the  IP-Address,  Subnet  Mask  and  Gateway.  Then  click  on  the 
"Name  Servers"  tab  (Figure  28) . 


Figure  28.  iPAQ  Wi-Fi  Wireless  Adapter  screen. 

(5)  Enter  the  DNS  Server  IP-Address  and  click  the 
OK  button  at  the  top  right  corner  of  the  screen  (Figure  29) . 


Figure  29.  iPAQ  Wi-Fi  Wireless  Adapter  screen. 

(6)  Read  the  text  box  (Figure  30) :  It  means  that 
you  have  to  turn  the  WiFi  off  and  on. 

(7)  Click  "OK." 
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Figure  30.  iPAQ  Configure  Network  Adapters  screen. 

(8)  Click  "OK"  until  you  are  back  at  the  main 
screen  (Figure  31),  then  turn  WiFi  Button  off  and  on. 
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Figure  31.  iPAQ  Main  Screen. 

C .  STARTING  TWIDDLENET 

Once  all  the  TwiddleNet  components  are 
connected/associated  to  the  selected  WiFi  network, 
TwiddleNet  can  be  started. 

1.  Once  the  "WiFi"  button  is  green  on  the  main  menu 
screen,  the  User  will  select  "Start."  From  the  drop  down 
menu,  the  User  will  then  select  "Programs." 
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2.  From  there,  "File  Explorer"  will  be  chosen.  Then 
the  user  must  click  on  the  down  arrow  to  produce  a  drop-down 
menu . 


3.  Selecting  "My  Device,"  another  drop-down  menu 
appears,  allowing  the  User  to  choose  "Program  Files, "  and 
then,  "TwiddleNet_application . " 


4.  This  selection  leads  to  another  drop-down  menu, 
where  "TwiddleNetCapp"  is  chosen  to  begin  the  TwiddleNet 
application.  Figure  32  illustrates  each  step. 


Figure  32.  TwiddleNet  Startup. 


1.  Client  Sign-in 

Each  Client  must  "Sign-in"  to  be  recognized  by  the 
Portal  and  the  TwiddleNet  program.  At  the  "SignInForm" 
screen  (Figure  33)  ,  the  User  will  enter  the  name  of  his/her 
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team,  i.e..  Team  la.  Team  lb.  Team  2a,  Team  2b,  Team  4a, 
Team4b.  The  password,  associated  to  whatever  team  the  user 
is  assigned  to,  is  then  typed  in,  i.e.,  teaml,  team2,  team3, 
and  team4 .  The  Password  is  case  specific,  utilizing  all 
lower  case. 


UsortvTiDe 

Password 


r' 

m 

Figure  33.  SignInForm  screen. 

When  the  user  has  successfully  signed  the  Client  into 
the  TwiddleNet  application,  the  German  National  Anthem  can 
be  heard.  This  indicates  that  the  Client  has  successfully 
signed  into  the  Portal,  the  Portal  has  validated  the  Client, 
and  written  verification  will  also  show  on  the  Portal 
screen.  When  validation  occurs,  the  Portal  will  store  the 
IP  address  of  the  Client  and  also  update  the  address  to 
reflect  the  current  user.  (Incidentally,  this  is  one  way  in 
which  the  Portal  tracks  the  IP  addresses  of  all  active 
Clients) . 

At  this  point,  the  Portal  retrieves  the  group  the  user, 
"belongs  to, "  in  addition  to  all  the  groups  utilizing 
TwiddleNet  at  that  time.  This  information  is  then  provided 
to  each  Client  so  that  the  Recipients  can  be  selected  for 
data  sharing. 
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2. 


Recipient  Selection 


After  the  sign  in  process  has  been  successfully 
completed  and  verified  via  Portal  verification  and  the 
completion  of  the  German  National  Anthem,  the  User  then 
chooses  the  Recipients.  This  is  accomplished  by  selecting 
the  box(es)  of  the  appropriate  Recipients  (Figure  8) : 
Medics,  Fire  Fighters,  Police,  Command  Post,  All,  and  None. 

D.  SIGNING  OFF  FROM  TWIDDLENET 

When  the  User  completes  testing  and  usage,  the  Client 
must  undergo  "Sign  Off"  procedures  from  the  TwiddleNet 
application . 

1.  Always  delete  all  shared/received  photos  from  the 
present  testing  session.  This  will  keep  the  memory  clear 
and  battery  life  optimal. 

2.  Always  "Quit"  TwiddleNet  application  on  the 

Client . 

3.  Always  disconnect  Client  form  the  associated 

network  by  selecting  the  WiFi  icon  on  the  iPAQ  Main  Menu 
screen.  (Ensure  the  WiFi  icon  is  brown  in  color)  .  This 

will  also  save  battery  life  when  the  Client  is  in  "Sleep 
Mode . " 

4.  Press  the  power  button  on  the  Client/Handheld 

Device  to  enter  the  smartphone  in  "Sleep  Mode." 

5.  Verify  written  verification  of  Client  "Sign  Off" 

on  the  Portal  screen. 

6.  Command  Post  Sign  Off 

a.  Quit  the  TwiddleNet  program. 
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b.  Verify  the  Command  Post,  "Sign  Off,"  on  the 

Portal . 

c.  Power  down  the  TwiddleNet  laptop. 

7.  Portal  Sign  Off 

a.  "Stop"  XAMP  application. 

b.  Quit  the  TwiddleNet  program. 

c.  Power  down  the  OQO  component. 

E .  RESETTING  TWIDDLENET 

1 .  Client  Freeze 

If  the  Client  "freezes  up,  "  wait  to  see  if  the  Client 
self  corrects .  The  handheld  device  is  sometimes  slow,  but 
will  finish  each  application  step  one  at  a  time.  If  the 
User  is  certain  that  the  Client  will  not  move  any  further, 
press  the  Reset  button  located  at  the  bottom  of  the  handheld 
device  (Figure  34) .  This  is  called  a,  "soft  reset."  After 
this  occurs,  start  the  TwiddleNet  application  normally. 
(NOTE:  Turning  off  the  handheld  device  will  not  work) . 


Figure  34.  iPAQ  Client  Reset  button. 
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2 .  Application  Reset 


To  reset  the  whole  application,  delete  the, 
"TwiddleNet,  "  file  (Figure  35)  .  That  will  delete  all  the 
user  settings  and  shared  content.  This  should  only  be  done 
if  nothing  else  works.  (NOTE:  Never  delete  the  file  that 
starts  the  TwiddleNet  application) . 
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Figure  35.  TwiddleNet  Application  Reset-  TwiddleNet  File 

deletion . 
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V. 


TESTING  DESCRIPTION:  ITERATIONS  1-4 


A.  CONTROLLED  LAB  TESTING 

All  iterations  were  tested  at  the  Naval  Postgraduate 
School  TwiddleNet  Network  Lab  (Figure  36)  .  At  this 
location,  a  dedicated  access  point  generated  a  stand-alone 
WiFi  network,  code  named  TwiddleNet.  The  access  point. 
Command  Post  and  Portal  maintained  dedicated  IP  address, 
while  the  Clients  were  issued  dynamic  IP  addresses  via  the 
DHCP  server. 

Additionally,  presentations  and  demonstrations  were 
conducted  in  this  lab  for  potential  research  sponsors  and 
general  interest. 

ACCESS  POINT  802.11 
192.168.1.1 

COMMAND 
POST /DHCP  SERVER 
192.168.1.2 

I  4 

t 

CIJENTS 

192.168.1.11-31 


Figure  36.  Naval  Postgraduate  School  TwiddleNet  Network 

Testing  Lab  layout. 


192.168.L4 
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B.  TESTING  SCENARIOS 

To  test  the  TwiddleNet  System  outside  of  the  NFS 
TwiddleNet  Network  Lab,  TwiddleNet  was  incorporated  into  the 
NFS  Cooperative  Operations  and  Applied  Science  &  Technology 
Studies  (COASTS)  in  the  pursuit  of  specific  scenario  testing 
of  all  TwiddleNet  iterations.  Since  2005,  COASTS  has  been  a 
collaborative  program  with  the  Royal  Thai  Armed  Forces, 
providing  a  venue  to  test  promising  technologies.  The 
specific  leveraging  aspects  of  COASTS  are: 

•  To  forge  relationships  between  key  organizations 
and  individuals  within  the  Royal  Thai  Armed  Forces 
and  US  DoD. 

•  To  gain  valuable  experience  through  technical 
demonstrations  and  field  experimentation 
(particularly  in  Southeast  Asia  and  Thailand) . 

•  To  document  processes  for  technology  assessments, 

•  To  provide  continued  support  by  NFS  Students  and 
the  0NR22  Frogram  (38  Reserve  Officer) . 

The  main  purpose  of  COASTS  was  to  experiment  with 
candidate  technologies  in  a  field  environment  to: 

•  Confirm  technology  maturity  and  CONOFS^s. 

•  Assess  candidate  technologies  and  provide 

operational  feedback  to  the  science  and  technology 
community . 

•  Frovide  a  venue  for  NFS  faculty  research  and 
Student  thesis  projects. 


22  ONR  -  Office  of  Naval  Research.  Coordinates,  executes  and 
promotes  the  science  and  technology  programs  of  the  United  States  Navy 
and  Marine  Corps.  [15] 

23  CONORS  -  Concept  of  Operations.  Generally  developed  from  a 
specific  concept  and  is  a  description  of  how  a  set  of  system 
capabilities  can  be  utilized  to  reach  desired  objectives  or  a  specific 
conclusion  for  a  certain  scenario. 
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The  COASTS  Field  Experiment  (FEX)  Series  was  designed 
to  ensure  technology  readiness  prior  to  insertion  into 
specific  scenarios  and  exercises.  Organized  FEXs  were 
conducted  at  Camp  Roberts,  CA  in  preparation  of  integrated 
EEXs  with  the  Royal  Thai  Armed  Forces  in  Thailand.  The 
following  were  the  major  field  exercises  and  scenarios  that 
integrated  TwiddleNet  for  testing  and  assessment. 

1.  Camp  Roberts  FEX  III  2008 

This  specific  FEX  presented  a  mock  real-world 
environment  that  imitated  the  natural  disaster  of  the  2004 
Boxing  Day  Tsunami^^  incorporated  Eirst  Generation 
TwiddleNet,  created  by  Clotfelter  and  Towle.  The  TwiddleNet 
system  utilized  the  COASTS  local  network  created  by  the 
Network  Operating  Center  (NOC) .  TwiddleNet  was  utilized  by 
the  COASTS  Mobile  Emergency  Command  Post  (MECP)  and 
dispatched  (on  cue)  to  the  affected  site  via  scripted 
scenario.  The  TwiddleNet  team  was  deployed  via  the  MECP 
First  Responder  vehicle  to  the  affected  site  where  data  was 
collected  and  disseminated  among  the  team  members  and  pushed 
to  the  JOCC .  This  scripted  scenario  (Appendix  A)  was  a 
rehearsal  in  preparation  for  FEX  IV  as  a  joint  exercise  with 
the  Royal  Thai  Armed  Forces.  Overall,  TwiddleNet 

functionality  was  a  success.  Pros,  cons,  and  major  results 
of  this  testing  were  presented  in  Chapter  II  and  synopsis  of 
the  after  action  report  (AAR)  is  provided  in  Chapter  VI. 

2004  Boxing  Day  Tsunami-  The  2004  Indian  Ocean  earthquake  was  an 
undersea  megathrust  earthquake  that  occurred  at  00:58:53  UTC  on  December 
26,  2004,  with  an  epicenter  off  the  west  coast  of  Sumatra,  Indonesia. 

The  quake  is  known  as  the  Sumatra-Andaman  earthquake.  This  tsunami  is 
all  known  as:  2004  Indian  Ocean  Tsunami,  Asian  Tsunami,  Indonesian 
Tsunami,  and  Boxing  Day  Tsunami. [14] 
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2. 


Thailand  FEX  IV  2008 


After  test  results  were  garnered  from  FEX  III  2008, 
Ableiter  and  Rimikis  made  appropriate  modifications  for 
Second  Generation  TwiddleNet.  The  TwiddleNet  team  then 
traveled  to  Parachuap,  Thailand,  for  a  joint  exercise  with 
the  Royal  Thai  Armed  Forces  on  the  Rayong  Air  Base.  The 
same  Boxing  Day  Tsunami  scenario  was  performed, 
incorporating  the  TwiddleNet  team  as  first  responders  for 
triage  tasking  and  information  dissemination.  Pros,  cons 
and  major  system  results  were  listed  in  Chapter  II  and  a 
synopsis  of  the  AAR  is  provided  in  Chapter  VI. 

3.  Thailand  FEX  V  2008 

FEX  V  was  again  located  at  Parachuap,  Thailand  at  the 
Rayong  Air  Base.  Third  Generation  TwiddleNet,  created  by 
Ableiter,  was  incorporated  into  the  same  Boxing  Day  Tsunami 
scenario,  deployed  as  first  responders  to  the  affected  site, 
code  named  Humanitarian  Assistance  (HA)  site.  Royal  Thai 
soldiers  were  utilized  as,  "victims"  to  enhance 
functionality  of  the  TwiddleNet  system. 

The  TwiddleNet  team  utilized  the  local  COASTS  WiEi 
network  generated  by  the  NOC .  This  WiEi  network  was 
expanded  by  a  backhaul  communication  link,  provided  by 
Western  Data  Communications  Technology,  to  the  HA  site. 
This  allowed  an  expansion  of  the  COASTS  NOC  WiEi  network 
spanning  several  miles  and  across  an  ocean  bay. 
Information,  data,  and  photos  were  pushed  from  the  HA  site 
to  the  JOCC  utilizing  this  communication  link. 
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Power  was  generated  from  portable  batteries,  which 
supplied  electricity  for  all  TwiddleNet  hardware  components 
and  the  backhaul  antenna.  All  TwiddleNet  components. 
Backhaul  Communications  components,  medical  triage  equipment 
and  TwiddleNet  medical  triage  personnel  were  transported  to 
the  HA  site  in  the  MECP  transportation  vehicle. 

Overall,  the  TwiddleNet  system  performance  was  a 
success.  Pros,  cons,  and  major  results  of  this  testing  were 
presented  in  Chapter  II  and  a  synopsis  of  the  AAR  is 
provided  in  Chapter  VI.  Several  onsite  photos  are  provided 
in  Figures  37-41. 
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Figure  38.  HA  site  w/Western  Data  Communications 
Technology  Backhaul  Communication  Link. 


Figure  39.  Royal  Thai  soldiers  portraying  injured 


survivors 
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Figure  40.  TwiddleNet  onsite  HA  setup. 


Figure  41.  TwiddleNet  onsite  Command  Post. 
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4. 


Camp  Roberts  FEX  III  2009 


The  results  collected  from  FEX  V  2008  allowed  Glidden 
to  modify  and  stabilize  Third  Generation  TwiddleNet,  leading 
to  the  most  reliable  iteration.  Fourth  Generation 
TwiddleNet.  Although  FEX  III  2009  did  not  incorporate  a 
specific  scenario,  it  allowed  a  venue  in  which  to  test 
TwiddleNet  with  other  emerging  technologies,  i.e.,  the  B-GAN 
satellite  for  backhaul  communication  link  to  the  JOCC .  This 
B-GAN  was  also  utilized  to  push/pull  information  and  data 
between  Camp  Roberts  and  the  NFS  TwiddleNet  Network  Lab  via 
the  TwiddleNet  Gateway  computer. 

Overall,  the  TwiddleNet  system  performance  was  a 
success.  Pros,  cons  and  major  results  were  presented  in 
Chapter  II  and  a  synopsis  of  the  AAR  is  provided  in  Chapter 
VI . 


5.  Thailand  FEX  IV  2009 

FEX  IV  2009  was  located  at  Jomtien,  Thailand,  on  the 
Satahip  Naval  Base.  Although  there  was  no  specific  scenario 
being  executed,  there  were  opportunities  for  continued 
testing  in  the  same  environment  and  several  opportunities 
for  TwiddleNet  presentation  and  demonstration  to  the  Royal 
Thai  Armed  Forces  other  VIPs. 

Overall,  the  TwiddleNet  system  performance  was  a 
success.  A  detailed  assessment  plan  was  provided  in  Chapter 
III  and  results  are  provided  in  Chapter  VI. 
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VI.  EXPERIMENTATION  RESULTS 


A.  TEST  DATA 

For  each  COASTS  FEX,  a  TwiddleNet  Test  Plan  (Appendix 
B)  was  submitted  to  the  COASTS  NFS  Team  Lead  to  ensure  all 
data  was  captured  in  a  complete  and  organized  fashion. 
Daily  situation  reports  (SITREPS)  were  submitted  each  day 
during  all  COASTS  EEXs . 

Raw  testing  data  for  the  first  three  iterations  of 
TwiddleNet  was  gathered  and  documented  on  TwiddleNet  Test 
Data  Sheets  (Appendix  C)  . 

B.  AFTER  ACTION  REPORTS  (AAR) 

AARs  for  all  TwiddleNet  testing  that  occurred  during 
each  COASTS  FEX  were  submitted  to  the  COASTS  NFS  Team  Lead. 

1.  Camp  Roberts  FEX  III  2008 

a.  Results 

Overall,  testing  was  successful.  All  MOEs/MOPs 
were  accomplished. 

Portal  functions  were  reliable  and  all  images 
captured  by  Clients  were  disseminated  to  all  TwiddleNet  Team 
Members  and  the  JOCC . 

Note:  Connectivity  was  intermittent  by  Handheld 
Clients,  but  all  captured  images  and  metadata  were  stored  on 
creator's  handheld  device. 
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b.  AAR  (Appendix  D) 

2.  Thailand  FEX  IV  2008 

a.  Results 

Positive  feedback  was  received  for  integration  of 
Royal  Thai  Armed  Forces  in  the  TwiddleNet  Humanitarian 
Assistance  Boxing  Day  Scenario. 

All  TwiddleNet  components  were  successful  in 
associating  to  the  local  COASTS  WiFi  network. 

Unfortunately,  issues  arose  with  heat  and  humidity 
affecting  the  TwiddleNet  Handheld  devices.  All  TwiddleNet 
Clients  were  successful  in  capturing,  storing  images  and 
metadata  for  approximately  10  minutes  before  the  system 
froze . 

b.  AAR  (Appendix  E) 

3.  Thailand  FEX  V  2008 

a.  Results 

Overall,  testing  and  scenario  execution  was 
successful.  Major  achievements: 

(1)  TwiddleNet  Medical  Triage  Team  were 
successful  in  gathering  and  disseminating  patient  data  in 
real-time  among  team  members,  the  TwiddleNet  Command  Post, 
and  the  JOCC . 
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(2)  System  functions  for  all  TwiddleNet 
components  occurred  as  expected,  exhibiting  system 
reliability . 

(3)  All  remote  C2  centers  received  real-time 
data,  raising  situational  awareness  of  the  Humanitarian 
Assistance  site. 

(4)  Backhaul  antenna  provided  by  Western  Data 
Communications  Technology  was  successful  in  linking 
TwiddleNet  WiFi  Network  at  the  HA  site  to  the  COASTS  WiFi 
network  located  several  miles  away. 

b.  AAR  (Appendix  F) 

4.  Camp  Roberts  FEX  III  2009 

a.  Results 

Due  to  severe  time  constraints  for  the  TwiddleNet 
researchers,  limited  testing  was  conducted  during  this 
COASTS  FEX.  Major  achievements  included: 

(1)  Successful  testing  of  Fourth  Generation 
TwiddleNet  conducted.  System  stability  and  reliability 
confirmed . 

(2)  Successful  testing  of  TwiddleNet  Gateway 
function.  Information  and  data  was  shared  between  the 
TwiddleNet  Gateway  located  at  the  NFS  TwiddleNet  Network  Lab 
and  the  TwiddleNet  Command  Post  located  at  Camp  Roberts,  CA. 
COASTS  JOCC  was  also  able  to  view  data  passed  from  the 
TwiddleNet  Gateway. 
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5. 


Thailand  FEX  IV  2009 


a.  Results 

As  stated  earlier,  there  was  no  COASTS  FEX 
scenario  executed.  FEX  IV  2009  provided  a  venue  for 

TwiddleNet  presentations  and  demonstrations  to  be  given  to 
Royal  Thai  Military  Forces  and  other  military  VIPs.  As  a 
result,  great  interest  was  generated  among  the  Royal  Thai 
Military  Forces,  requesting  market  availability  for  the 
TwiddleNet  Application.  It  also  provided  the  opportunity 
for  a  comprehensive  assessment  to  be  conducted  for  Fourth 
Generation  TwiddleNet. 

Additionally,  successful  testing  was  conducted  for 
the  following: 

(1)  Multithreading  of  Clients. 

(2)  Group  Sharing  function  for  individual 
TwiddleNet  Teams . 

(3)  Automatic  re-association  of  Clients  into  the 
COASTS  Local  WiFi  Network  after  travel  outside  of  WiFi 
radius . 

(4)  Automatic  re-association  of  Clients  when 
awaken  from,  "sleep  mode." 


C.  PROS  AND  CONS  OF  FOURTH  GENERATION  TWIDDLENET 

As  stated  earlier,  COASTS  FEX  IV  2009  provided  a  venue 
for  the  comprehensive  assessment  of  Fourth  Generation 
TwiddleNet.  A  narrative  of  the  comprehensive  assessment 
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plan  was  provided  in  Chapter  III  within  the  Metrics  Overview 
section.  The  complete  Fourth  Generation  TwiddleNet 
Assessment  Plan,  to  include  testing  results,  is  located  in 
Appendix  G. 

1 .  Pros 

a.  Fourth  Generation  TwiddleNet  exhibited  an  overall 
95%  performance  reliability  resulting  in  the  most  consistent 
and  dependable  iteration. 

b.  Consistent  data  dissemination  during  multi¬ 
threading  option. 

c.  Consistent  data  dissemination  during  group  sharing 
function . 

d.  Consistent  reliability  of  Clients  ability  to  re¬ 
associate  into  local  WiFi  network  after,  "sleep  mode,"  and 
when  re-entering  WiFi  cloud  radius. 

(1)  All  captured  data  was  stored  in  Client  files 
until  re-association  into  WiFi  network  at  which  time  data 
was  sent  to  Portal  for  further  dissemination. 

2 .  Cons 

a.  There  were  no  major  technical  issues;  however, 
there  were  several  minor  observations.  They  are  as  follows: 

(1)  TwiddleNet  Clients  have  only  an  80%  ruggedization 
percentage.  HP  iPAQ  Smartphones  are  several  years  old  and 
need  to  be  replaced  with  more  a  robust  model. 
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(2)  There  was  an  intermittent  20%  degradation  with  the 
operating  distance.  This  was  not  completely  understood  and 
therefore,  future  testing  should  be  conducted  in  this  area. 
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VII.  SUMMARY  AND  CONCLUSIONS 


A.  APPLICATION  TO  THE  DOD 

As  mentioned  earlier  in  this  thesis,  the  main  objective 
of  TwiddleNet  was  to  use  a  smartphone  based  networking 
application  for  first  responder  triaging  during  humanitarian 
assistance/disaster  relief  missions.  However,  future 
applications  of  TwiddleNet  can  be  expanded  to  enhance  other 
DoD  missions. 

For  example,  current  research  for  Fifth  Generation 
TwiddleNet,  conducted  by  LT  Chey  Hock  Sim,  Singapore  Navy, 
and  LT  Hong-Aik  Lee,  Singapore  Navy,  proposes  a  new 
architecture  to  expand  system  capabilities  to  allow  cross 
networking  for  information  sharing  [15] .  This  could 
potentially  lead  to  an  expansion  of  the  triage  area, 
allowing  several  first  responder  teams  to  deploy  to  several 
disaster  areas  with  continuous  capabilities  for  data 
collection  and  dissemination.  This  would  undoubtedly  lead 
to  greater  situational  awareness  for  all  C2  centers  and 
major  decision  makers. 

TwiddleNet  could  also  be  integrated  with  other  emerging 
technologies,  i.e..  Unmanned  Aerial  Vehicles  to 
surreptitiously  gather  environmental  data  at  a  greater 
distance  to  gain  an  overall  assessment  of  the  target  area. 

Further  exploration  into  the  realm  of  covert 
information  gathering,  TwiddleNet  could  be  utilized  to 
secretly  capture  and  distribute  photos  and  images  of 
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specific  targets/persons  of  interest  during  confidential 
missions,  to  distribute  false  images  to  mislead  an  adversary 
or  for  tactical  deception. 

B .  FUTURE  WORK 

This  work  represents  potential  improvement  in  the 
overall  TwiddleNet  system.  There  is  great  opportunity  to 
increase  overall  range,  the  number  of  deployed  teams, 
network  security,  and  the  triage  graphical  user  interface. 
These  suggestions  are  strictly  from  a  user  perspective  as  my 
expertise  does  not  encompass  programming  skills.  Some 
thoughts  are  listed  below. 

1 .  Network  Linking 

As  mentioned  earlier.  Fifth  Generation  TwiddleNet  is 
exploring  the  possibilities  of  expanding  the  range  and 
number  of  deployed  teams  by  linking  two  or  more  networks 
together.  This  would  increase  the  deployable  range  and  allow 
sharing  between  two  or  more  networks,  greatly  enhancing  an 
overall  situational  awareness  of  the  affected  area(s) .  This 
research  could  possibly  include  utilizing  satellite 
technology  for  more  far-reaching  capabilities,  and  to 
receive  data  and  instruction  from  other  medical  facilities 
in  networks  around  the  world. 

2.  System  Security 

Currently,  the  only  encryption  available  to  TwiddleNet 
is  WEP  encryption,  which  leaves  vulnerability  gaps  within 
the  system.  To  enhance  encryption,  TwiddleNet  could  be 
incorporated  with  emerging  technologies,  such  as  GHOSTNet-  a 
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secure  and  anonymous  Virtual  Private  Network  (VPN)  service. 
Coupling  Ethernet  tunneling  and  proxy  services  to  provide 
users  safe  and  anonymous  Internet  access,  GHOSTNet  utilizes 
TSL  (SSL)  protocol  with  AES-256  encryption  to  secure  the 
network  along  with  PKI  certificates  and  HMAC  protection  from 
replay  attacks  and  UDP  flooding  [17] . 

3.  Triage  Graphical  User  Interface  (GUI) 

Currently  the  GUI  for  the  triage  tasking  is  very  basic 
and  rudimentary.  A  more  explicit  graphical  form  with  more 
drop-down  menus  could  be  generated.  This  would  save  time 
for  the  user/triage  team  member  by  eliminating  the  need  to 
"type  out"  notes  regarding  injuries  and  current  medical 
condition . 

Eor  this  improvement,  a  dedicated  and  experienced 
programming  engineer  would  have  to  be  employed. 

C.  CONCLUSIONS 

This  work  successfully  tested  and  evaluated  all 
iterations  of  the  TwiddleNet  Networking  application.  We 
conclude  that  this  system  is  extremely  worthwhile  and 
beneficial,  with  a  strong  foothold  in  the  realm  of  adhoc 
networks  for  first  responder  medical  triaging.  TwiddleNet 
has  been  extremely  successful  in  the  field  for  gathering  and 
disseminating  information,  images,  and  data  in  real  time. 
This  is  an  unmistakable  advantage  in  gaining  situation 
awareness  for  all  command  and  control  centers  and  for  all 
decision  makers. 
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with  continuous  incremental  improvements  in  reliability 
and  stability.  Fourth  Generation  TwiddleNet  has  quickly 
become  an  extremely  powerful  and  valuable  system,  with 
unlimited  possibilities  of  future  developments,  DoD 
integration,  and  commercial  network  optimization.  It  is  my 
hope  that  a  dedicated  (and  funded)  R&D  program  will  bring 
TwiddleNet  into  marketable  productization  in  the  very  near 
future . 
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APPENDIX  A.  EXCERPT  COASTS  TSUNAMI  SCENARIO  SCRIPT 


COASTS  FEX  I\'  TwJddEcNct  Stcn^irio  Script 


Background 

An  unexpected  tropical  stom's  racing  across  ihc  Gulf  of  Thailand 
has  led  to  a  category  4  Typhoon  causing  flash  flooding  in  the  small 
coastal  town  of  Rayong,  Thailand.  Sixty  minutes  following  the 
coitelusion  of  the  typhoon^  the  COASTS  ME  CP  is  deployed  to 
assess  damages  and  set  up  triage  area.  Additionallyj  a  Military 
Operation  in  Urban  Terrain  (MOUT)  within  the  main  city  of 
Rayongj  Thailand  (to  seize  and  secure  key  combatant  targets)  has 
been  delayed  due  to  the  typhoon.  MUOT  to  lake  place 
approximately  sixty  minutes  following  the  coinpletion  of  the 
typhoon,  in  order  to  maintaiii  the  element  of  surprise. 


Hititianjlarian  .XHiitaDCi:  Fliate-i  fin  black  font) 

00:QO  f  COMEX.  Sixty  minutes  after  the  conclusion  of 

the  tropical  typhoon^  MECP  is  deployed  to  disaster  area  iji  order  to 
assess  damages  and  set  up  triage  area.  Concurrently,  Military 
Operations  in  Urban  Terrain  (MOUT)  and  clearance  and  capture  of 
enemy  personnel  from  Urban  Built-Up  Areas  (UBUA)  by  the 
COASTS  Combined  Task  Force  (CTF)  has  commenced.  Thirty 
minutes  after  the  completion  of  the  MOUT,  the  MECP  is  dcploy'cd 
to  set  up  triage  area.  The  CTF-CO.ASTS  liaison  to  COASTS  team 
requests  assistance  to  sun^'cy  the  scope  of  the  injuries  i  casualties, 
search  and  rescue  for  injured  survivors  and  initiate  initial  medical 
triage  efforts  for  two  locations.  After  an  additional  hour  of 
coordination  and  crisis  planning,  CO.ASTS  has  determined  how 
best  to  support  this  request  and  coordinate  the  support  with  the 
host-nation.  Time  elapsed  since  MOUT  completed  +02:00. 

OOjOI  JOCC  Directs  AU‘23  Mosquitos  to  be  launched  from 
Wing- XX  and  dispatched  to  disaster  region  and  MOUT  area. 
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00:0 1  JOCC  D  irccfor  (Ck-  ] ):  ^'Airboss,  JOCC,  laur.ch  aJcrr  AL'-2 J  lo  FLOOD 

PCgLDlJ.” 

Airbois  |Ch-l):  ^Rogcr.  launch  aLcn  AU-21'" 

00:01+30  Airboss  fX-HF):  "’MoRquito  01 ,  Airbosn,  launch  apjd  depart  to  FLOOD  area. 
Dc-pon  on  ground  rouics  and  extcni  of  damage” 

MosquEro  OJ  fVHF):  '"Rager,  launch  apjd  depart” 

00:02+30  Airbfiss  fVHF):  '’Mosquito  02,  Alf^mss,  launch  apjd  depart  to  M<JLIT  area, 
report  on  ground  routes  and  cxrcni  of  damage” 

MosqaEto  02  (VHF):  "Roger,  launch  and.  depart” 

00:03  MosquECo  01  (VHF-iowerj:  ‘■'Rayong  Toiler.  Mosquito  01  ready  for  lakeoff, 
rumomto  north  wes-t  and  depart:u.re  to  wutk." 

Tower  (VHF):  Provides  nece^-sary  clearanee. 

00:10  MotquEto  02  (\''HF-toi^  cr):  "Rawng  TaTS.Tr,  Mosquito  02  ready  for  rakeoff, 
rumo'iit  to  noithwcs-t  and  deparrnre  to  semth." 

Tower  (VHF):  Ehovides  necessarr' elearanec. 

00:02  JOCC  Directs  two  Mobile  Eniicrgcncy  Comiriand  Post 
(MECP)  Tcains  to  depart  Joint  Operation  Coinniand  Center 
(JOCC)  for  MOUT  zone. 

00:02  JOCC  Direef  or  (Ch- 1 ):  -'M  EC  P- A,  JOCC.  dejwi  for  flood  7onc” 

MFCP-A  (Ch-l):  ^'Roger,  departing” 

OOiOi  mCC  Dirccfcr  (Ch- 1 ):  ^'MECP-B.  JOCC.  depart  for  MOt.T  ;'one" 
MFCP-B  (Ch-1):  "  Roger,  departing” 

00:0-4  JOCC  Director  (VOiP):  '’E^'F.  JOCC.  transit tn  cFfshore  nf  flood  aonc” 

PCF  (VOIP):  '■^Roger,  dcaarxing” 

00:20  jAU-23  arrives  over  FLOOD  area,  video  provided  to 
COASTS  JOCC  and  to  remote  sites  via  COASTS  network.  PCF 
arrives  in  MOUT  area. 

00:20  MosquEto  01  iVHF):  ''lOCC.  Mosquito  01.  1  am  over  FLOOD  scnc  nors'. 

Many  resort  baildings  have  sustained  signifieant  damage.  Large  number  of 
bodies  In  and  around  hcaeh  landseane.  Will  transmit  video.” 

JOCC  Dircetor  (VHF):  "Mosquito  01,  JOCC,  lindcrstand  significant 
damage,  loss  of  Life  and  injured  KJWs  /  nancomibaTarirs,  waiting -on  video” 
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<M:25 


OZ  fVHF):  'TOCC,  Mosquilo  02,  [  am  over  MOLT  area  noi^'. 
Fj^tinfi  in  FonLficd  ObjcctiviH  (FOFO)  has  suHcained  KLenificanr.  danr.a£i?. 
Large  number  of  bodies  in  and  around  urb-an  landscape.  Will  rransmit 
video.’ 

JOCC  Dircetor  fVFiF):  '‘MDsquLto  02.  JOCC,  understand  iigniflcanl 
damage,  loss  of  life  and  injured  K>Ws  i  noncombaiancs.  wailing,  on  l  idco" 

00:2^^^-3a  PCF  iVOlP}:  ’’JOCC.  PCF,  I  am  offsborc  from  FLOOD  7onc.  [  contlm 
repon,  sigcii^cant  damage  and  bodies  awash  in  waier." 

JOCC  Dirccior  (VOIP):  '’PCF,  JGC’C,  [bant  you  for  coniirmatLon'' 

OOiZO  Tin^elitic  coinprcssioii.  60  ininutcs  simulated  elapsed. 
After  short  survey  of  disaster  areas,  routes  are  determined  into  the 
area  for  disaster  relief  teams  and  military  extraetion  teams.  JOCC 
relays  tliis  information  to  the  inbound  MECP  Teams.  Both  AU-23s 
use  loiter  eapability  to  remain  over  both  areas  and  provide 
continued  SA  and  support.  Both  MECP  teams  arrive  in  disaster 
areas  within  seeonds  of  each  other. 

00:20  M  KCP  (S ATCOM):  '^JOCC,  M  EC  P-A,  wc  have  airived  in.  FLOOD  lone. 

Lnitialinfi  setup.  wtLl  [aunch  12. K\'.  standby  far  video.  TwiddlcNet.  and 
reporting” 

Jt>CC  Dlrcclor  (SATCOM):  “Roger  MECP-A,  JOCC  standing  by'" 

00:22  M  ECP  {S ATCQM):  '^JOCC,  M  EC  P-B,  we  have  arrived  in  MOLT  area, 

initiating  setup,  will  launeh  UAV.  standby  for  video,  TwiddIcNet.  and 
ceporting” 

JOCC  Director  (SATCQM):  "Roger  MECP-B,  JOCC  standing  by 

00:50  MECP  teams  set  up  complete  (including  TwiddleNct) 
and  initial  reports  data-linked  back  via  satellite  /  B-G.^N  to 
COASTS  JOCC.  Mini-LbW  supports  MECP,  reporting  on 
damage  and  possible  survivors  to  surrounding  area  through  aerial 
surv'ci  [lance. 

00:50  MECP- A  CS.ATCOMl:  ^'JOCC.  MECP-.A,  you  snould  be  receiving  indeo. 

UAV  vidcfl,  and  T4.id{lleNct.  FLOOD  region,  has  i^ifTencd  iigtiillcant 
damage  to  aJl  buildings;  many  sunivcirs  have  sustained  extensive  injuries. 
This  is  a  major  disasier  zone,  inland  road  smjcture  is  inract,  but  refugees  arc 
flooding  The  nettvoTh.  Local  cammunicacLDns  arc  dav.'n.  Medical  assistance 
and  housing  needs  have  piionty.” 
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JOCC  Director  CSATCOM}:  ^'MECP-A,  JOCC,  Rogcj,  teill  na£s  your 
[□forniaciDn  to  highcT,  continue  obEcn'Btion  and  ccponing  " 

00:54  MECP-ltJiATaJMl:  '^JQCC.  MEtP-B.  you  should  be  rcoeiving  video, 
UAV  video,  and  Twiddle-Net.  hfOLiT  area  tias  sufTened  significant  damag.c  to 
several  buitdlnes:  enemy  POWs  and  noneombatant  sun  ivors  have  s-ustained 
extensive  injuries.  This  is  a  major  dLsascet  zone.  Inland  road  stroetuce  is 
intact,  but  rePugees  arc  flooding  the  network.  Local  communications  arc 
down.  Medical  assistance  and  housing  needs  have  priority." 

JOCC  Director  (SATCO.M):  '‘MECP-B.  JOCC,  Roger,  will  pass  your 
informarion  to  higher,  continue  ohscrvaiLon  and  neporting" 


QiO;S6  Reports  on  damagc/scopc  of  disaster  re  fayed  froni 
COASTS  JOCC  to  host -nation  Command  Center  and  loeal  KGO 
headquarters  in  eapitaL 

00:5  H-  JOCC  D  irecCor  (Finnic):  Malics  eontaet  with,  hosi-nati  on  command  centon  s  J 

and  local  NCiO  headqiiartejs  to  c-onfimi  neceipl  of  information 

1  FINEX:  Mini-UAV  re eo vers,  MECP  teams  return 
to  base. 
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APPENDIX  B.  EXAMPLE  TWIDDLENET  TEST  PLAN 


J'rnm:  LiJIijn  A..  Abuoa.  LC.  OR.  .SC, 

Uir1(  Ablcicer.  I.f,  CiNV 
COASTS 

Tiq:  Jini  L'^lcrl 

COASTS 

Subj:  l-l?;  «[  E'^EDCiLI  MiiFEVALLATJuX  ICSI  I'Lan 

.1 .  Dv^riJI  iind  dsily  ahjecnves: 

a.  Sccnuin:  [Jff'la-).'  x  Mabile  l:cnn£e:>:y  Coini=iE.nd  J'du  |  MllCE’T,  ualiT'.'nf  \31dI1,  l;^hL 
'p.i<LE;hL!acridhe!d.s  su^^paru  bz^icbtul  cuom -n:cal:ons  fniTn  a  d:<E.:lar  Tiona  to  L'CLA 
Tilcmcdicmc  icn,:ET 

b.  U';i j»  I  v-'iddlEbal  far  funiadaa  nflaisd.  med^ral  ina|iE  ciuin^  daring  ro^niEln’ 
riumjn.ilarian  r)p<i. 

r.  T'widdlEb  rI  lo  laic  arid  Evaluaca  'Jie  trfEcbv-crKics  of  olJ  oquipmaR:  :.s:ooLii[,Kj 

rapr.jnnE.aad  dixbaninp  rrizgE  in:ag»;  uiaorh  ziformaLion  Jloiir. 

±  U:idxE  I  widdlEb  r1  to  ciaala  iin  laiioK'niiidurE  Lni:  dEnar,;^  l  hiErz.rch.y  far  irraLTia 
Eicd'-iTioTi,  info  gz.1hEring,  z.ad  djstr.'badan  in  azdarto  zjieI;,'7c  apcinial  sn'.ulaan; 
raniplacrly  avaliiac:  xir-iiioQlhric'iEh  capauK  imogEr,  forliigoHl  opdijial  ulaniaai. 
a.  Crtoir-  a.  ilap  by  seep  dKrsioa  pracars.  :a  b«~.  rqaip  Cirsc  Tanpandan  nbra  pnapajlng  in 
diipiicrh.ai[L 

-.  riniE  hloclc.1  aicparlad  far  CHtiog.  h^'Llb^  LbosE  Lma  b^rJu.' 

a.  f'annnruJ  raqairad: 

S}  Oiric  .A IbaicEr,  Cilain  .'Ibuoxi 

2)  1  pairan  lEam  to  uie  [>Er.pheri.'.  TuiddlaSIatECi'-ipinralba  La::  funatonaLty  li'.ringa 

mui  cacunity  ■  rianian.iljrian  migE  irEnirjo. 

b.  Lqaipmanc  jEq^-irrd 

I J  1'widdlE^E1  J'nrial  ink  OOO  isnuJI  aarapucEri 

2)  i  IJandhEiol  dEvioai-rjinizip  T’ArddlENEt 

T)  Oaa  laptop  running  tha  C'orr.mand.  Posi  (Didr'i  compular) 

4}  CvEiylbinE’-siag  diE  givEn  narui'ork 
a.  '^Ijard"  and  "SnfL"  □malinas 

:)  VVEatnaiday:  Saring  up  of  I  wiiidlahai  todd  ]7ClO 

t.  LlriJI  dovi'n  farT'A-idd^Nac  sal  up  Lad  aqujpn'.EnI  usea 
Ij  I  hursdiy: 

£.  Sarlinp  up  Mohija  Cammaad  Rost 
b.  Idandfy'ing  Command  and  Contra]  lliarzrchy 
r.  Cnnd'.^::  latting  (reen  CWfl  JVllO 

■  t:  Ctandamly ieJce  piarrraiwitn  flva  lla1,lra^ 

i]mullunaa'i.^ly  jn  automarir  modn  {'.iJce  tem  "^  .12?) 

']  ast  'dnu  hnhrcidlng''  ( JCi  min,  J  aam :  S] 

■  !b.k;'f  2:  Sama  as  ona  but  aniar  diffaraas  lags  witn 
kayboudfJd  min,  laam:  f } 

■  S.L. J  2:  JiSLJ.  I. imilad  davira  lEsanp. 

i.  Maas'jrHS  of  LtTacnvraES* ;  Maasurus  of  I'Erformanca  far  aquipman:  ya'.'rE  tailing 
L.  Tatm  ab.liry  tolaka  photos  and  drsbuna  'ta  PCTk  T,AL  and  .STECR 
b.  jJon  sbarinp  rapabshtias:  spaad,  idtta  ofdLta 

4.  Jadapaodenl,  dapandmL,  and  ronlrniilad  vnnablxs  {Taiprrtis  aly:  What  ynu  ‘rr  rntn|;in.g  aaob  limE, 
H'hai  you'ta  mEESuring,  and  vt'dai  says  Iba  siniE  for  raah.r-Tt;i 

5.  JJau  tEqunad  fmai  oihar  COaSIS  niambars:Ci.E.  ,ARHS  tjJ'S  localion,  MCTt'JC  info) 

t.  ba'A’cek  infn 

b.  Topology  diagnm  -  skalah  .'  dairriptino  of  whart  you  ora  salting  up  aquipm-tm,  if  appli-iabia 
1.  T!ltD.  'T‘bE  IriapE  TEim 'AilLdiiltiursa  vrrhin  WiFi  radt'-t. 

7.  Maina  fur  data  a  all  Err  ion  wbatparomnars  yar.  inicnd  to  riptutE  li  indEpradant  variable 
rhzjigas. 

i.  Data  p.aibanng  Limits:  bauary  lifa  af  handhelds,  craa  n-f  aparanon.  n-aamar  anndinaas, 
Equipmant  a  ffirtamy 
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APPENDIX  C 


TWIDDLENET  TEST  DATA  SHEET 


A  BCD  -  --  -  F  C  H  ■  '  I  ■  J  k  L  M 


DATE/ 

HANDHELD 

USED 

Connection  of 
WiFi  Dotsdec 

IP  Dotoction  by 
ALL  HarCwaro 

Proxy  Son/or 
Detection  by 
ALL  Hardware 

Connoction 
EstabiistieO 
between 
Handheld 
Devices  t  Data 
Sha^  fY/Nl 

Multithreading 
Capability  by 
Handhelds 
(Y/N) 

Viewabie  Data 
seen  by  All 
Handhelds 
(Y/N) 

Remote  Video 
viewable  by 
Portal  /  Mobile 
Command  Post 

Remote  Video 
viewable  by 
JOCC 

Ability  to 
Remotely  View 
Pictonal  Data 
by  Commar>d 
Post  Server 

Abil'ty  to 
UPDATE 
Pictonal  data 
w/  written 
comments 

INMARSAT 
Cor>ncction 
Detected  by 

ALL  Hardware 
(Y/N) 

Data  shared  by 
ALL  Hardware 
•jsi.hg 

INMARSAT 
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APPENDIX  D.  TWIDDLENET  COASTS  FEX  III  2008  AAR 


JK  J  thruDR' 


fTnir:  Lir.itn  A.  Abunn,  LCbK,  SC. 

Uirk  Abkic^r.  LI'.  fi.SV 
COASTS 

To:  Ji^  IaIctI 

COAST. S 

Siibj:  I  LX  ELI  IM1>[JL.E  'SL  I  ULMaM  [  AKIAS  ASSlSiT.A.'JCL  SCILNAKIO  TLil 

ASfJ  I^'ALL.AlJfJS  KJ:SLiLTS 

1.  CverLlI  objcdLvcs: 

a.  SrraunD:  Lteplay  j.  .UDbjIc  lIiziCT^ZKy  Cc-TTir^LTid  I'ni;  IMLLP),  ubli^.Tig  joidI:,  L^hc 
ii'cighLlaudhdld.s  bui  supcnrl!;  bM'^htuI  cnram'.nical^ani  fnas)  a  dma^ur  nonii  [o 
lOC  Cf  Ebr  Dnenti^iDD  rad  disinburon  to  du-UCLA  iclEmcdJrine  ce^iEr 
h.  li'lliM  T'<A'idjdlErr1  farfuncdon  iteljicd.  incd;:j!  iriauc  laicingduriog  [rui-ii  ruuE.ln'.' 
auinjELitanan  op;. 

c.  thiljiiX’T'iA'ididlEb'rl  lo  le;:.  atieI  cvaliuK  'Jie  crfEciivsiMii  of  oil  equEpmcn';  Ebr 

EDpr-rin^  and  djiibuiTL'np  bria^e  iiragn;  s:riiio:h  afbrniJLbn  Ilou'. 

1  Ll:idaM  T'^'iddlcbn  to  mak  an  LTina;.iriir1ijrE  lm:  dcnutH  alnerajcliy  far  scEnanD 
d^.aL'^:iaa,  lafo  palhEring,  Lnd  disCr.budDn  in  unicrbci  zjilIv^f  Dpdnnl:  saL'uton. 
EDopIftE’l;^  EvaLuaiE  -tiimdcci  Ihro'-gh  capoiTdi  imagci  For  hi^bEjtlcpliznal  uliLEiaas. 

E.  CrrisE  2  klEp  by  sisp  dtcLilon  pcvcEs:.  :n  bdii  tqu^a  firs:  TE!kpnndEr3'  i^'iiETi  prcparinji;  :d 
dispji-ih.  rid. 

2.  TwMddleNd  EquifHnent  ccsicd 

a.  T'v.'iddLcN-EC  PcmaL  Link  000  (mobile-  computer  located  in  [he  MECP 
vehicle) 

b.  4  Handheld  devices  running  T-^'iddieNce 
G.  T-^iddicNct  Lapmp  located  i[  the  TOC 

d.  Available  ^'iFi  newort 

3 .  Me-asutes  of  Effectiveness  .■'  Measures  of  Perlbrmance 

a.  TOC  CP  (laocon  ::  SL'CCLSSFCL 

-  reoeived  iniagcs  and  data 

--Note:  "'REFRESH  ’  bunon  needed  to  be  pressed  for  receipt 

b. MECP  j'OTOL  SLCCESSFLL 

-  received  images  and  data 

a^  NOTE:  c  umently  receiving  same  tmag.es  :  data  as  TOC 
b)  FUTURE;  need  more  independence;  HIE R.4RCHY 

Cn  Handhelds  (2>  MECP.-'OQO  (3)  TOC  C4)  TELE  MED  UCL.d 

-  PORTAL  ^Gtion  SLCCESSFLL 

c.  INTERNAL  SYSTEM  APPLICATION:  SL'CCESSFLI. 

-  Handliclds  able  to  take  pboios. 

a)  NOTE:  delay  tarween  photos  longer  than  expected 

-  Multithreading:  SUCCESSFUL 

a)  Handhelds  able  to  take  photo-s  simultaneously  and  send  to 
Portal  for  dtsbibution 
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d.  CONNECTIVITY:  IMEHMITTENT 

al  No-  Lndlcatian  of  nan-canncctivity  bj'  handhcld-s- 

—images  RtoTcd  on  hiJuihcldH  until  comiccti'i’icy  lecKcabliKhed 
—NOTE:  Dirk  creating  and  implcinc-r.ting  nir.v  jsTQgram  for 
rcal-tlnnc  indicadon  of  conncctiiirity';  debugging, 
sysvcm 

b)  Imcnnirtmt  conncctivicv'  occurring  when  MECP  vehicle  in  low 
areas  surcaunded  by  hills 

4.  Fuiuie  Testing 

a.  [ntplcmenting  'Tcady-made”  triage  forms  for  on-sire  medical  evaluarion 
h.  M  EC!  P  /  T OC  Hieiarchy  cs-labtishcd ;  independent  rceeipt  of  mfQraiaic.Dn 
c.  GHOSTNer  for  Handhelds 
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APPENDIX  E.  TWIDDLENET  COASTS  FEX  IV  2008  AAR 


26  Mirch 


FrcniJ  LlLltan  A,  Aisuaji 

lc::r  EC  y5:j 

CGA5I5 

To:  JiiT.  Ehlert 

Pragrar.  Kar.ager 
CGASCE 

Via:  J’lar  EurlEcrez 
LCGP  UEf-: 

CGP.5TS 

Set;:  COASTS  FEK  IV  200“  ThAILANIi  F'JXAKITAJf  I  All 

A5E I  STANCE  A>iD  TIST/EVALL'ATICN  OS  TSJIDIIEWET  AFTER  ACTIGK 

REPORT  'AARJ 

1.  f'agar  Acl’.ievetr.arrs 

■  H.ur.ar.i.tariap.  Scer.arln 

aj  Positive  teeiback  tor  Ir.tegraiior.  oi  Ttai 
coLr.terparia  ror  participation  ir.  dlsa stair 
drill 

Dj  PcsitlvG  teeitiEck  tor  Ir.tegratlor.  o; 
Corpsnren  rasErvlats 

sj  Positive  tEEitisck  lor  location  or  lEA  slta 

■  iKidcieHeC  aysterr 

a]  Positive  test  lor  associating  to  iroblie 
access  points r  i-a.,  JGCC_A?,  HC_A.? 

n]  T'KlC.dleNet  JOCC  Coirtr.ancl.  Post  Server 
positive  last  lor  associating  ar.O 
recognition  oC  Twidllati’et  Portal 

cj  TViCdieNet  Handle  id  devices  /"  clients 
positive  test  lor  tn.age  b  dats  gathering 
ano  sharing  w,-'  otter  devices  /  clients  via 
TviddielJet  Portal 

dj  IwlddieNei  Kandheid  devices  /  clients 
positive  test  lor  storage  ot  all  Irrage  a 
da  ta 


2.  Hagor  Prodlenrs 


■  TwiddleNet  Handheld  devices  /  clients  severely 
attected  Py  teat  and  tumidity 
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All  devL-::E3  able  to  capi^rej  siore,  sliere 
ir.ages  t-ar  appx.  LD  r.ir.a  he  tare  ireezlng 
h)  •TEjr.star.t  regettlr.g  Dt  device  required 

c]  'Zn/erheattr.g  occiirrlr.g  cor-slstently  wttJiir  5 
r.ir.Lites  Qt  ir.trodiiciiDr.  It. to  envlroTrrjenc . 

d)  [JdoIlTg  ra  lor.ger  alleviated  issde 
e3  ?rograir  ucatle  to  run  or.  .’■lardrields 

fj  Error  Tnesaages  occumr.g  wlttin  h  mlriutea 
c-t  rdr.T  Lng  prograr. 

g3  Issde  still  L.r.re£aivel^  Suspect  program, 
viil  Ltave  re  be  rei-aaled 


■  “wlddieWet  ays  tern  unEJi  Ie  to  he 
ro  lack  ot  Ketwork 


rested  early  d;:e 


■  ?cur  coir.rr.s  lurlr.g  scerarlo 

a 3  Very  ditticnlt  to  bear  /  urderstar-d  .JCCC 
reajn  leader 

h3  Nc  coier.s  wizb  PC  tor  eiitractlcr  port  tor:  or 
acEr.ario 


Lessar.a  Learr.ed 


■  Probieir.L 

a 3  Ji?  1P.S.QS  are  rot  robust  eTough  to  har.die 
erviror.ir.en.r 

t3  flard  tel-l  radios  rot  stror.g  era  ugh  lor 
listar-ce  trcin  t-te  JOIC 

■  Deacrlptlor.  ■ 

a)  Cc-cilir.g  syatein  rot  s  no  ugh  tor  teat  t 
niiinidlty 

Lea  SOTS  learned  L 

a 3  AnteTras  cn  har-dheida  not  strung  er.ougJi  to 
break  this  ugh  3^F  Interterence  cauair.g  ur.it 
to  coTstanily  work,  harder  /  tetter 

03  Processor  cuoltr.g  syaien.  not  atrong  enough 
tor  er.vlr cr.T.ent 


■  Solution : 

a3  Acquire  tetter  .handheld  cJ  Lenta 
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APPENDIX  F.  TWIDDLENET  COASTS  FEX  V  2008  AAR 


Dir.  /  LCDR  Abuair 
AaH 


Major  Ac  bie-ycnn  cn  tsj 

1)  TwiddleNei  L’^nablcd  '.ht  Mc-dLal  Tria^i:  Tcarr.  co  Eharc  pa^iLiil  dnia  and  mcdicat 
lTia££  infocmaticr.  in  icaL-iirp.c  asnong.  chc  [cam  incmbcri,  as  well  as,  with  Ihc 
McibiLc  EmcTECRizy  Command  Posr  ac  ihc  Hum.anir.anan  .Assistanr  siljc  and  ihc: 

Joint  Operations  Conimani  Cmiler. 

a)  Al]  LPAQ  handbcLd  devLees  able  to  [ate  and  ncccLvc  pho[Ds:  MultirnrcadLug 
Successful. 

b]  Al]  handhcLds  able  [o  receive  audio  alcnt  from  other  handhcLds 

ci  Portal  (OQG)  able  to  visually  dispLay  each  specific  handbeld  upon  association 
/disasEociation  [o  PertaL. 

d}  Portal  it>QO)  displayed  written  alcn;  upon  teceipiy  distribution  of  each  Image 
taken  by  aLL  handhelds. 

2)  Remote  command  ccntcra  were  able  to  g.ct  com.picte  sitnaiional  ai^  arcness  of  the 
H'jmani larian  Assistant  site  in  real-time  Viith  pictures  and  annotated  texi. 

a)  Photos  tagged  Vrich  personal  PT  info 
b}  Photos  tagged  with  medical  triage  information 

JJ  Nctv.'0[t  cloiid  esiabiishcd  to  covet  200  yd.  radius  at  Humanitarian.  .Assistance  site 
using  Western  Dala  Communications  iechnolo.gy:  SUCCESSFUL 

aj  Ti^iddleNct  associated  w-  Western  Data  Carmn'jnicatLons  Case:  .SUCCESSFUl 

b}  Rcdline  S02.16  backhaul  established  for  connection  of  Humanitarian 
.Assisranec  sire  and  JOCC:  SUCCESSFLTL 


Major  Prabtems  {(LndLeste  If  unresoLved} 

1)  \TR 

Ltsutns  Lcarnedi 

L)  Pr-Oihltmt  Associarion  of  phones  with  open  WiFi  networks 

Dfscriptiou:  TwiddlcMct  eontinualty  artemipiing  to  associate  with  multiple  open 
VViFi  networks  and  dropping  Ihc  designated  W''iFi  network  (HI.'_.AP} 

Solution:  Stabilise  software  apnlication  to  mLainiain  connection  with  dedicated 
WiFi  network  (  HU  AP> 

2)  Problem:  Unstable  cameras 

DeserLptiou:  Cameras  on  iPAQ  hardware  stow,  unabLc  to  take  multiple  photos  in 
quick  succession,  would  continually  freejie  during  use  of  application. 

Solution;  Acquire  stronger  and  faster  hardware,  which  is  now  available 
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J)  Problem:  Requires  pbouc  pne-corLfiguratlsn  for  siaiLc  IP  addresses 

DeserLptioo:  UiiabLe  lo  auiomaiicaLLy  associate  TwiddLcNK  hardware  to 
dedicated  WiFi  □eiU'Orfe.  Must  eontLmiillj'  input  static  IP  addressee  m  ordei  for 
associa'ang  HA_LiP  Comms  Case  to  Tw  iddleNet  hardware. 

Siolutlon:  .^Itow  ccunma  case  or  dcdicaied  WiFi  network  on  aJiorted  range  of  IP 
addresses  and  assign  to  TwiddleNet  hardware  via  DKCP. 

45  Problem:  X-o  spceiJlcd  Thai  cranslai-or 

Description:  There  was  no  specified  trartslator  to  communicate  with  Thai 
couaLct^rta  volunteering  as  Tsunami  StiJ%'Lvors 

Siol  urlo  n:  Idenii  fv'  translator  prior  to  1 "  drv'  run  of  scenario.  Maintain  the  same 
volunteers  as  tsunami  survivors  to  maintain  condnuil^'  of  e.'tpeTicncc  and 
knowledge. 

65  Problem:  No  covered  area  for  rain 

Description:  No  available  tent  for  protection  from  weather  elements.  Unable  to 
procure  "pop-up”  tent  from  nearby  lowm 
Solution:  Procure  “pop-ijp’'  tent  From  BangkoJe 

7)  Problem;  No  llghtln.g  available  For  Kumanitarian  Assistance  site 

Description:  For  night-time  scenario,  Humanitanan  Assistance  site  MUST  have 
light  for  Inc  following  reasons: 
a}  S.AFETY 

b5  CLEAR  [M.A<}EC.APrU  RE 
c}  SET  L'P  (5F  EQUIPMENT 
Solution:  .Acquire  genetaconfs)  and  flood  tights 

h)  Problem:  Bad  radio  comms  ^  No  comms  plan  used 

Descrlptioo:  Radios  used  were  not  strong  enough  for  clear  comms  from 
H'jmanltarian  Site  to  JOCC.  The  comms  plan  that  was  available  was  not  'jsed. 
Solution;  .Acquire  stronger  radios.  Populate  and  use  the  comms  plan. 
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APPENDIX  G.  TWIDDLENET  FOURTH  GENERATION  ASSESSMENT 

REPORT 


T1A  IDDI.ENET  ASSESSMENT  REPORT 

I>I.SCR]PTI0>’3 

>  Tw iddlcNrt  is  an  XPS  gionsored  ptroi'cct  co  icvclnp  a  anarphcKic-faaKcd  system 
tn  racilitatc  instantancDus  cantjre  of  data  in  support  of  nr.edicad.  triage  ttrbar. 
aasauEty  i^  artighler  oatra]  /  H.AZMaT  response  [ha.t  ean  be  tagged  and 
dtsscnitnaied  iiiicig;  any  niobile  WLf  i  network. 

>  LlnlLaing  CatninericiaL-a[T-the-Shelf  eomponejiti,  T!SI  team  mcnibcrs  maintain 
complete  autonomy  of  all  eaptcjed  data,  which  is  shared  amon^  speciiled  team 
memners,  stored  for  redundancy  by  the  Command  Perst  server  and  later 
d'scriminately  shared. 

>■  100%  gaif-  of  enhanced  situational  awareness  for  mobile  monitoring  dtiti  ng  all 
types  of  seal  able  ojierationi. 


OBJECTIVES  FOR  CV09 

>  TwiddleNet  peifonnance  data  will  be  collected  and  analyzed  during  Crimson 
Viper  2  009. 

>-  The  overall  assessment  strategy  tor  C  V09  TwiddleXet  is  to  evaluate 

Effectiveness,  Stiitabiliw.  and  Mission  Impact  of  the  various  ccmipeiiicntH  under 
pliyslcaLly  demanding,  eondilions  k  with  different  network  CDniig.uraiLons. 

>  Document  environmental  data,  nerwori:  tadtus  &  unc-ontiollabLe  variables 
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>  Documcni  [:[ivirDnm.cnril  duta.  radius  iL  uucop.trQLljbLc  variables 

>  Measures  and  dara  SQurets  wnlL  address,  CQls,  Objccthcs,  MOEs  and  MOSs  as 
well  as  a  data  calLecti-sn  ap.d  analysis  approach 

>  Experiment  O'T'erview.': 

a  All  componen' s  assembled  and  end-Lo-end  rransmissiojis  confirmed  by  TN" 
Cmd  Post 

Q  Aecess  to  imagcS’  daia  on  Cmd  Posr  sen-er  tests  rmm  remole  locarions 
o  Handhelds  tested  at  ditTenenr  disrancea  ibr  rcltability' '  speed  of  data 
transfer 

Q  System  cantinuiry  documeniasion.  rcaablcshooting,  and  eoutse  cotrcction 
a  System  tes;  of'Group  Feature"  and  simuLtaneous  data  muLtllhrcading 
a  Wif  i  tlo'jd  area  tested  with  Fly  Away  Kk 

RESLLTS 

>  Analysis  Res:jJr  1-6:  SiJceessfulLy  eompLctcd  all  objectives.  Analysis  of  results 
contained  in  concltiiions. 


1  34uniT- 

8—1  n. 

SfOh  l-l-J  Pn^bmKcrciiihilitJ  ptf 

rcA'tx'ft 

MOI:  Irl-t:  Piirnii ’prclBli  nplumlind  ihiinl 

mAtXA 

HDdi  1-L.S:  Pai«ni  Dt  diu  iweit  td 

TL'A'CX.A 

^(Ol:  l-t-i:  r'tirciit«7HiAw.'Bre  raLi^rl!' 

TUaiAa 

JTOS 

MO};  1  -t-f  ■  rtliiJillilV 

Tt'ACKA 

HiHBn  Smm'  Fradad 


MOi:  l->-]:T‘Khkllt’b'Kin«f4ETti.  rqs)sdi2stlm 

TCaCK'A 

H0*:v 

MO};  1  -;-j.  potwiB  .prifismiw  dM*  nwel^fil  ■'  ip  ifie 

HAd 

‘rCA.OCA 

100% 

1  -2-t  BWwfsei' 

TTA.WA 

Ml?];  1-2-1  b^K  uf uri  ■  Ktn  ISV  Woifidhtni 

Tt'AIOtA 

im% 

MOJ:  l-2-f!:CliiiHH’C!lTrsti:  rtmpcnAsi:  uid  HiunlilJlr 

•nCAOCA 

0% 
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MtlE  Z-^  -t.  otfit  U]>  IB 

TIIIA.'OCA 

30  mlM 

'MUt  Avnuc  euh  ^  iyiIid  to  be  I^IIik  DcrcibMal 

“Tlatxa 

^'0  mim 

MD£  l-l-'lLAma.m'  batlirv  Iik  -d fH wtbclJ^^'KEi. 

TC.A'OCA 

MOKJ  l-t  IlftnfCJQO 

TC’AWA 

Afcn 

MQE  2-1  -S:  r^'unftKr  and  iyp:  nt  tHomBi 

tc:A:Oc:a 

S  .A 

Smuh 

2d- 1  [*  TiisiBS(?Jci  W'uem  imu  ' 

Tt-A^XA 

S+CT  2-2-Z  [■»  <h*  rtiy  (p  >r?!lnur!l^ 

TTA-tX:^ 

Mt;>K  3-3-3;  A^  pm.O'  Kquircmm  muiiubta ' 

TtlA.ffl'A 

VKS 

UatlBiEi  ■ 
LiouRanrl 

1  Mihhtp 

Smiw 

hndvEl 

MOb  2-3-] :  li  torh  GL'1  eaftr  to  cuiiidrcJtoDd  hbI  tDoOrUn^ 

TCAOtA 

VbS 

MCM:  2-3-2.  Dvn  dn  TkivUIe-SicI  lyvinii  etAhke  bkt  uluUKind 

ovi'anTKH? 

TCAOCA 

YLS 

MOb  2-3-2:  Mow  nnidi  Ininiriii  lime:  n  nr^wd  fw  tic  mvirt 

TCA.ttfA 

M{>H  2-3-* 

TCA.tXA 

rbs 

MOI:  3-3-F  lA  fcVi]inric  dneuaWKtofi  4.vuaiM(  ^  4C  imf  to  -tft 

TfA‘t1!JA 

vi:& 

C:t>>'CLL:SI()NS 

>  (?5^i>  Overall  Kuc  ceFa  race 

>  !?5%  Performance  RclLabtLLly  due  kq  mineiT  issues  ■wlln  data  sfiacin^ 

>■  SCi^'ci  RugeciLzaiiofi  -  subjective  score  based  on  nry  assessmem 

>  20^i.  Dsgradatian  with  operati  ng  distarLce  -  Not  coinplelclv  undsrslcKjd.  More 
research  w/  Dr.  Singh 

RE  COMMEND  ATI  ON  S 

>  Major  TechrJeal  Issues 

a  XothiT.g  to  Report 
V  Minor  T cchnical  Issues 

a  WLFi  Cloud  rcLLabi]Lt>' 

Q  WiFi  must  be  turned  otT on  harjdhclds  when  in  sleep  mode 

■  To  accommodate  consen'atLon  of  battety 
a  Sy stcon  rel  iabilLn''  during  peilods  of  id  leness 

■  Handhelds  must  be  used  at  least  once  every  hour  to  maintain 
conncctiviry  to  system. 
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>  Pachi  Ahtad 


a  PurchasE  new  Smartphone  with  inaie  RA^{,  Eernger  battery  life,  better 
eainera 

■  Itiereasc  robustness 
a  Enlarge  WiFi  clenii 

■  PnidLasc  oatdocr  aecess  points  to  create  WAX 

a  Explore  pc-ssibiLity  of  use  with  other  icchnologiis,  L.e.  U.AVs 


DISTRO 

L'nelassiiied 
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